Il existe une question simple qui met mal à l’aise la plupart des comités de sécurité : si un attaquant repartait ce soir avec une copie intégrale de votre base de production, que verrait-il exactement ? Beaucoup d’organisations répondent que les données sont chiffrées. Peu savent dire qui détient les clés, où elles sont stockées, quand elles ont été renouvelées pour la dernière fois, et si l’administrateur qui a accès à la base a également accès au coffre qui les protège. C’est précisément dans cet écart que se joue la valeur réelle d’un dispositif de chiffrement.
Cet article traite du chiffrement tel qu’il se pratique dans un système d’information d’entreprise, et non tel qu’il s’enseigne en cours de cryptologie. Le choix des algorithmes y occupe une place modeste, parce que ce choix est largement tranché par les autorités techniques. La gestion des clés, elle, occupe la place centrale, parce qu’elle constitue le point de défaillance de la quasi-totalité des projets. À jour au août 2026.
Ce que le chiffrement protège, et ce qu’il ne protège pas
Le chiffrement garantit la confidentialité d’une donnée face à quelqu’un qui obtiendrait le support ou le flux sans détenir la clé. Il ne garantit rien d’autre, et surtout pas la sécurité d’un système dont les accès légitimes sont compromis.
Cette distinction est la source de la plus grande partie des malentendus. Un disque chiffré protège contre le vol d’un ordinateur portable dans un train, contre la revente d’un serveur mal effacé, contre la récupération d’un disque défectueux par un prestataire. Une fois la machine démarrée et la session ouverte, ce même disque est parfaitement lisible pour tout processus autorisé, y compris celui que pilote un attaquant ayant volé des identifiants. Le chiffrement au repos ne voit pas la différence entre un utilisateur légitime et un intrus qui a pris sa place.
Il faut donc formuler le raisonnement à l’envers de l’intuition courante. La bonne question n’est pas de savoir si les données sont chiffrées, mais contre quel scénario précis ce chiffrement est censé protéger, et si ce scénario figure réellement parmi les risques prioritaires de l’organisation. Un chiffrement mal ciblé produit un sentiment de sécurité sans réduire le risque dominant, ce qui est plus dangereux qu’une absence assumée de chiffrement.
Le contexte français rappelle où se situe le risque dominant. Selon le Panorama de la cybermenace 2024 de l’ANSSI, plus de la moitié des opérations de cyberdéfense les plus engageantes de l’agence ont eu pour origine l’exploitation de vulnérabilités affectant des équipements situés en bordure du système d’information. Autrement dit, l’entrée se fait par une faille exposée, puis par des accès légitimes usurpés. Aucun de ces deux mouvements n’est arrêté par du chiffrement au repos.
Les trois états de la donnée : au repos, en transit, en cours d’utilisation
Une donnée se trouve toujours dans l’un de trois états, et chacun appelle une technique de protection distincte. Confondre ces états conduit à croire une donnée protégée alors qu’elle circule en clair sur un segment interne.
Au repos, la donnée est stockée : disque de serveur, volume cloud, sauvegarde, base, poste de travail, support amovible. On la protège par du chiffrement de volume, de système de fichiers, de base ou de champ applicatif. Plus le chiffrement est appliqué près de la donnée, plus il est sélectif et plus il protège contre les accès internes, mais plus il coûte en complexité applicative et en indexation.
En transit, la donnée circule sur un réseau. TLS en est le mécanisme quasi universel, aussi bien pour les flux externes que pour les flux internes, y compris entre microservices, entre l’application et sa base, et entre les nœuds d’un cluster. L’erreur la plus répandue consiste à sécuriser rigoureusement l’entrée du système d’information puis à laisser les échanges internes en clair, au motif que le réseau est de confiance. C’est exactement l’hypothèse que la démarche Zero Trust invite à abandonner.
En cours d’utilisation, la donnée est chargée en mémoire par un processus, donc en clair. C’est l’état le moins protégé et le plus convoité par les attaquants. Les technologies d’informatique confidentielle, fondées sur des enclaves matérielles, apportent une réponse partielle sur des cas d’usage précis, mais elles restent aujourd’hui une option d’architecture et non un standard de déploiement.
Choisir ses algorithmes : ce que recommandent l’ANSSI et la CNIL
Le choix des algorithmes n’est plus un sujet de débat en entreprise : les autorités techniques publient des listes explicites, et s’en écarter demande une justification que peu d’équipes peuvent produire.
La CNIL détaille dans sa fiche sécurité consacrée au chiffrement les mécanismes considérés comme sûrs. Elle recommande SHA-2 ou SHA-3 pour le hachage, bcrypt, scrypt, Argon2 ou PBKDF2 pour le stockage des mots de passe, AES avec un mode de construction approprié tel que CCM, GCM ou EAX, ou encore ChaCha20 associé à Poly1305, pour le chiffrement symétrique. Pour l’asymétrique, elle cite RSA-OAEP, ECIES-KEM ou DLIES-KEM, et pour la signature RSA-SSA-PSS ou ECDSA. Sur les tailles de clés, la même fiche considère que 128, 192 ou 256 bits sont suffisants pour AES, et recommande pour les algorithmes fondés sur RSA des modules d’au moins 2 048 bits ou 3 072 bits. Elle proscrit explicitement DES, 3DES, MD5 et SHA-1.
L’ANSSI publie de son côté un ensemble de guides consacrés aux mécanismes cryptographiques, dont un guide de sélection d’algorithmes qui liste les mécanismes standardisés à l’état de l’art et alerte sur les erreurs d’implémentation observées dans des produits réels. Le point de méthode qu’il martèle mérite d’être retenu par toute équipe de développement : concevoir soi-même un mécanisme cryptographique est un exercice réservé à des spécialistes, et un développeur non spécialisé doit s’appuyer sur des bibliothèques éprouvées en respectant scrupuleusement leur guide d’usage. La quasi-totalité des failles cryptographiques exploitées en production ne viennent pas d’un algorithme cassé mais d’un algorithme mal employé : vecteur d’initialisation réutilisé, absence d’authentification du chiffré, comparaison de secrets sensible au temps d’exécution.
Pour les flux, les recommandations de sécurité relatives à TLS publiées par l’ANSSI fournissent le référentiel attendu lors d’un audit : versions autorisées, suites cryptographiques, gestion des certificats. En 2026, une configuration défendable n’accepte plus que TLS 1.2 correctement paramétré et TLS 1.3, et considère TLS 1.0 et 1.1 comme des dettes à résorber sans délai.
Du côté international, FIPS 197 normalise AES et NIST SP 800-57 Part 1 Revision 5 constitue la référence sur la gestion des clés, notamment sur les durées d’usage recommandées selon le type de clé. Ces documents sont utiles lorsqu’il faut argumenter une décision d’architecture auprès d’un auditeur ou d’un client international.
La gestion des clés : le vrai sujet du projet
Un dispositif de chiffrement vaut exactement ce que vaut la protection de ses clés. C’est la seule phrase de cet article qu’il faut retenir si l’on n’en retient qu’une.
Le cycle de vie d’une clé comporte six moments, et chacun peut ruiner l’ensemble. La génération doit reposer sur une source d’aléa de qualité, sujet sur lequel des incidents célèbres ont montré que des générateurs déterministes produisaient des clés prédictibles. Le stockage doit placer la clé hors d’atteinte des mêmes personnes et des mêmes processus que la donnée qu’elle protège. La distribution doit garantir qu’une clé n’est communiquée qu’à un composant authentifié. La rotation doit permettre de renouveler une clé sans interruption de service, ce qui suppose de gérer plusieurs générations simultanées. La révocation doit pouvoir invalider une clé compromise sans attendre. La destruction doit être irréversible, car une clé encore présente dans une sauvegarde ancienne annule toute logique d’effacement cryptographique.
Le principe structurant se résume à la séparation des rôles. Si l’administrateur de la base de données dispose également des droits sur le coffre de clés, le chiffrement n’a rien protégé : il a simplement ajouté une étape à un acteur qui possède déjà tout. Cette exigence de séparation rejoint directement les problématiques d’identités machine et de gestion des secrets, car une clé consommée par une application est un secret comme un autre, avec les mêmes travers : présence dans un dépôt de code, dans une variable d’environnement journalisée, dans une image de conteneur publiée.
Un point de méthode reste trop souvent négligé : la procédure de récupération. Une organisation qui chiffre sans avoir formalisé ce qu’elle fait en cas de perte de clé s’expose à une indisponibilité définitive de ses propres données. La CNIL recommande d’ailleurs explicitement de rédiger une procédure décrivant la gestion des clés et des certificats, en prenant en compte les cas d’oubli du mot de passe de déverrouillage. Cette procédure doit être testée, comme on teste une restauration de sauvegarde, faute de quoi elle n’existe que sur le papier.
KMS, HSM, BYOK, HYOK : démêler les modèles
Dans le cloud, quatre modèles de maîtrise des clés coexistent, et le vocabulaire commercial entretient une confusion utile aux fournisseurs. La question qui les départage est unique : qui peut techniquement déchiffrer vos données sans votre accord ?
| Modèle | Où vit la clé | Qui peut déchiffrer techniquement | Usage typique |
|---|---|---|---|
| Clés gérées par le fournisseur | Chez le fournisseur | Le fournisseur | Défaut de la plupart des services managés |
| KMS client (CMK) | Chez le fournisseur, sous votre compte | Le fournisseur, avec vos autorisations | Cas général en entreprise |
| BYOK | Importée par vous, hébergée chez le fournisseur | Le fournisseur, tant que la clé est active | Exigence contractuelle ou sectorielle |
| HYOK | Chez vous, jamais exportée | Vous seul | Données à très forte sensibilité |
Le modèle KMS avec clés gérées par le client couvre la majorité des besoins réels : il apporte la journalisation des usages, la rotation automatisée, le cloisonnement par politique et la possibilité de révoquer. Le BYOK est souvent présenté comme un gain de souveraineté, alors qu’il déplace la confiance sans la supprimer : une fois la clé importée dans le service, c’est bien l’infrastructure du fournisseur qui l’utilise. Le HYOK, où la clé ne quitte jamais un HSM sous votre contrôle, est le seul modèle qui répond réellement à la question de l’accès par un tiers, mais il impose des contraintes fortes de disponibilité et de latence, et il est incompatible avec de nombreux traitements côté fournisseur.
Ces distinctions prennent tout leur sens dans un débat de souveraineté. Un hébergement en France ne change rien à la juridiction applicable à la maison mère d’un fournisseur, alors que la localisation exclusive des clés, elle, a un effet technique concret. C’est l’un des points examinés par la qualification SecNumCloud de l’ANSSI, et un critère structurant pour toute organisation qui construit une stratégie de cloud souverain en France.
Chiffrement et conformité : RGPD, NIS2, DORA
Aucun de ces textes n’impose le chiffrement de façon absolue, mais tous le placent parmi les mesures dont l’absence devra être justifiée après un incident.
Le RGPD cite le chiffrement à l’article 32 comme exemple de mesure technique appropriée, aux côtés de la pseudonymisation. L’effet le plus concret se situe toutefois à l’article 34 : lorsqu’une violation concerne des données rendues incompréhensibles par un chiffrement robuste dont les clés n’ont pas été compromises, l’organisme peut être dispensé d’informer individuellement les personnes concernées. Le chiffrement devient alors un levier direct de réduction de l’impact médiatique et opérationnel d’un incident, ce qui change la nature de l’arbitrage budgétaire. La notification à l’autorité, elle, reste due dans les conditions décrites dans notre guide sur la notification d’une violation de données à la CNIL en 72 heures.
Le volume de ces incidents progresse nettement. Le rapport annuel 2024 de la CNIL indique que l’autorité a été notifiée de 5 629 violations de données personnelles sur l’année, soit 20 % de plus qu’en 2023, et fait état de 331 mesures correctrices dont 87 sanctions pour un montant total dépassant 55 millions d’euros d’amendes. Ces chiffres situent le contexte dans lequel une décision de ne pas chiffrer devra être défendue.
La directive NIS2 mentionne pour sa part, parmi les mesures de gestion des risques attendues des entités essentielles et importantes, les politiques relatives à l’usage de la cryptographie et, le cas échéant, du chiffrement. L’exigence n’est donc pas seulement technique : elle porte sur l’existence d’une politique documentée, ce qui suppose de savoir dire quelles données sont chiffrées, selon quels mécanismes et sous quelle gouvernance des clés. La trajectoire d’ensemble est détaillée dans notre guide NIS2 pour l’entreprise. Pour le secteur financier, DORA va plus loin en attendant une politique de chiffrement formalisée, incluant la gestion des clés et le traitement des cas où le chiffrement n’est pas applicable.
Déployer : une trajectoire en six étapes
Un projet de chiffrement échoue rarement sur la technique et presque toujours sur le périmètre. La séquence suivante limite ce risque.
- Cartographier les données avant de chiffrer. Sans classification, le chiffrement s’applique soit partout, ce qui coûte cher et ralentit tout, soit au hasard. Cette étape rejoint le prérequis de classification déjà décrit dans notre analyse de la prévention des fuites de données.
- Traiter d’abord le transit. Généraliser TLS sur tous les flux, y compris internes, est l’action au meilleur rapport effort sur risque, et elle ne demande aucune modification du modèle de données.
- Chiffrer les supports par défaut. Postes, terminaux mobiles, supports amovibles et sauvegardes hors site doivent être chiffrés sans exception, car ce sont les seuls cas où le vol physique reste un scénario courant.
- Choisir un point de gestion des clés unique. Multiplier les coffres, les magasins de certificats et les secrets applicatifs revient à multiplier les points de compromission. Un service centralisé, journalisé et adossé à un HSM constitue la cible.
- Ajouter le chiffrement fin là où il compte. Champs de santé, données bancaires, secrets industriels, identifiants directs. Ce chiffrement applicatif se justifie par la menace interne et par les exigences sectorielles, pas par principe.
- Éprouver la récupération et la rotation. Tant qu’une rotation n’a pas été réalisée en conditions réelles et qu’une restauration à partir d’une clé archivée n’a pas été testée, le dispositif n’est pas opérationnel.
Cette trajectoire s’articule avec les autres chantiers de résilience. Le chiffrement des sauvegardes, en particulier, ne remplace pas leur immuabilité : ce sont deux propriétés distinctes, décrites dans notre article sur la sauvegarde immuable face aux rançongiciels.
Les erreurs qui reviennent le plus souvent
Cinq écueils expliquent l’essentiel des dispositifs de chiffrement inefficaces observés en audit.
- Stocker la clé à côté de la donnée. Fichier de configuration sur le même serveur, secret en dur dans le dépôt de code, clé dans une image de conteneur. La donnée est chiffrée, la protection est nulle.
- Ne jamais renouveler les clés. Une clé en service depuis huit ans, utilisée par des dizaines de composants dont plus personne ne tient la liste, ne peut plus être révoquée sans provoquer un incident majeur. La rotation ne s’improvise pas après coup.
- Confondre hachage et chiffrement. La CNIL le rappelle explicitement : une fonction de hachage seule ne garantit pas la confidentialité d’une donnée, car une empreinte issue d’un ensemble de valeurs prévisibles se retrouve par simple énumération. Un hachage de numéro de téléphone n’anonymise rien.
- Chiffrer sans plan de récupération. Le risque d’indisponibilité créé par le chiffrement peut dépasser le risque de confidentialité qu’il traite, si aucune procédure de séquestre et de restauration n’a été formalisée et testée.
- Ignorer la durée de vie de la confidentialité. Certaines données doivent rester secrètes vingt ans. Pour celles-là, la menace de collecte immédiate suivie d’un déchiffrement ultérieur est déjà actuelle, ce qui impose d’anticiper la migration vers la cryptographie post-quantique.
Ce qu’un RSSI retient
Le chiffrement est une mesure de réduction d’impact, pas une mesure de prévention d’intrusion. Il transforme un vol de données en incident de disponibilité et de réputation limité, à condition que les clés soient restées hors de portée. Cette condition est la totalité du sujet.
Les décisions qui comptent tiennent en trois lignes. Décider quelles données méritent quel niveau de protection, ce qui suppose une classification. Décider qui détient les clés et qui ne les détient pas, ce qui suppose une séparation des rôles assumée jusque dans les habilitations. Décider comment on renouvelle, révoque et récupère, ce qui suppose des procédures testées et non des intentions.
Le reste, c’est-à-dire le choix des algorithmes et des tailles de clés, est déjà écrit par la CNIL et par l’ANSSI. Une équipe qui applique ces recommandations sans chercher à innover, et qui investit l’énergie ainsi économisée dans la gouvernance de ses clés, obtient un dispositif nettement plus solide que celle qui débat de courbes elliptiques pendant que ses secrets dorment dans un dépôt Git.