Comprendre le chiffrement des données personnelles : le guide essentiel

Comprendre le chiffrement des données personnelles : ce que le RGPD attend vraiment de vous

Un client m'a appelé un mardi soir, paniqué. Sa base de données clients venait de fuiter. 14 000 enregistrements, noms, adresses, IBAN. Le pire ? Les données étaient stockées en clair. Sa première question n'a pas été « comment on répare ? » mais « est-ce que je risque quelque chose avec le RGPD ? ». Réponse courte : oui. Réponse longue : tout dépend de ce qu'il aurait dû mettre en place avant l'incident.

Et c'est là que le chiffrement entre en jeu. Pas comme une case à cocher dans un tableau Excel de conformité, mais comme la différence entre « on a perdu des données » et « on a perdu des données illisibles ».

C'est quoi le chiffrement des données, concrètement ?

Le chiffrement des données, c'est l'opération qui transforme un texte brut lisible en texte chiffré illisible, à l'aide d'un algorithme et d'une clé cryptographique. Seule une personne détenant cette clé peut redonner du sens à ce charabia.

Pour visualiser : imaginez un coffre-fort. Vos données sont dedans. La clé, c'est… la clé. Sauf qu'ici, le coffre peut se dupliquer à l'infini et voyager sur n'importe quel serveur sans que son contenu soit lisible par un tiers.

Un peu d'histoire (et pourquoi ça compte)

La première technique de chiffrement connue remonte au code de César, vers 58 avant notre ère. Jules César décalait chaque lettre de son message de trois positions dans l'alphabet. Basique. Aujourd'hui, on parle d'algorithmes qui manipulent des clés de 256 bits — soit 2^256 combinaisons possibles. Un nombre à 78 chiffres.

Ce saut technologique n'est pas anecdotique. Il explique pourquoi le chiffrement est devenu la brique de base de toute conformité sérieuse au RGPD.

L'objectif réel : empêcher la lecture par des personnes non autorisées

Le but du chiffrement n'est pas de rendre les données « indisponibles ». Il est de les rendre incompréhensibles pour quiconque ne détient pas la clé. Nuance importante quand on parle de violation de données : si un attaquant vole un disque chiffré, il vole… du bruit.

Le lien que personne ne fait : chiffrement et RGPD

Vous avez sûrement lu que le RGPD « impose » le chiffrement. C'est faux, ou plutôt : c'est incomplet. Le texte ne dit nulle part « vous devez chiffrer ». Ce qu'il dit, à l'article 32, c'est que vous devez mettre en œuvre des mesures techniques et organisationnelles appropriées pour garantir un niveau de sécurité adapté au risque.

Et parmi ces mesures, deux sont explicitement citées : le chiffrement et la pseudonymisation.

Dans les faits, quand la CNIL instruit un dossier de violation, la première question posée est : « les données étaient-elles chiffrées ? ». Si oui, le risque pour les personnes concernées est souvent jugé faible, et la notification individuelle peut ne pas être obligatoire. Si non, vous recevez une notification à 72 heures, et vous la devez à chaque personne dont les données ont fuité.

J'ai vu un dossier où cette différence a coûté 0 € à une entreprise, contre une amende à six chiffres pour une autre. Même secteur, même type de fuite. Une seule variable : le chiffrement.

Quels sont les 7 principes du RGPD ?

Le chiffrement n'est qu'une pièce. Voici les sept principes que tout traitement de données personnelles doit respecter :

1. Licéité, loyauté et transparence — vous devez pouvoir justifier chaque traitement.
2. Limitation des finalités — une donnée collectée pour une raison ne peut pas servir à une autre sans base légale.
3. Minimisation des données — ne collectez que le strict nécessaire. Le fameux « au cas où », c'est non.
4. Exactitude — les données doivent être à jour.
5. Limitation de la conservation — une durée définie, pas « indéfiniment parce qu'on ne sait pas ».
6. Intégrité et confidentialité — c'est ici que le chiffrement vit.
7. Responsabilité — vous devez être capable de prouver votre conformité.

Le sixième principe est celui qui vous concerne directement ici. Et le septième explique pourquoi « on chiffre nos données » ne suffit pas : il faut pouvoir le démontrer, documenter les algorithmes utilisés, les tailles de clés, les procédures de rotation.

Quels sont les 3 types de données personnelles ?

On classe généralement les données personnelles en trois grandes familles, selon leur sensibilité et le niveau de protection qu'elles exigent.

Type	Exemples	Chiffrement attendu
Données identifiantes	Nom, prénom, adresse, email	AES-256 au repos suffit dans la plupart des cas
Données sensibles	Santé, origine ethnique, opinions politiques, orientation sexuelle	Chiffrement renforcé + accès restreint + journalisation
Données bancaires et de connexion	IBAN, carte bancaire, adresses IP, logs	Chiffrement de bout en bout pour les transactions, tokenisation recommandée

Un mot sur les données de connexion : on les oublie trop souvent parce qu'elles ne « ressemblent » pas à des données personnelles. Une adresse IP est pourtant considérée comme une donnée personnelle dès qu'elle permet d'identifier une personne, même indirectement.

Quel est le chiffrement le plus sécurisé ?

Franchement, la question est mal posée. Il n'y a pas un chiffrement « le plus sécurisé » dans l'absolu, mais des algorithmes adaptés à des usages différents. Voici comment je classe ça, après plusieurs années à conseiller des PME sur le sujet.

AES-256 : le standard de fait

C'est ce que j'utilise pour tout ce qui concerne les données au repos. Chiffrement symétrique, une seule clé pour chiffrer et déchiffrer, rapide, éprouvé. La taille de 256 bits est aujourd'hui considérée comme résistante à une attaque par force brute, même avec des ordinateurs quantiques hypothétiques.

RSA-4096 : pour l'échange de clés

RSA est un chiffrement asymétrique : une clé publique pour chiffrer, une clé privée pour déchiffrer. Sa lenteur le rend inadapté aux gros volumes, mais il est excellent pour transmettre des clés symétriques. Minimum : 4096 bits si vous voulez dormir tranquille.

ChaCha20 : l'alternative moderne

Léger, rapide, conçu pour les environnements où AES est moins performant (mobilité, objets connectés). C'est ce que Google utilise pour certaines connexions TLS. Choisi quand vous avez des contraintes matérielles.

Ma recommandation concrète, si vous ne voulez retenir qu'une chose : AES-256 au repos, RSA-4096 ou ECDSA pour les échanges, ChaCha20 si vous avez des contraintes de performance sur mobile.

Ce qu'on oublie toujours : la gestion des clés

Voici la vérité que personne ne veut entendre. Le meilleur algorithme du monde ne sert à rien si votre clé est stockée dans un fichier texte à côté de vos données.

J'ai vu une configuration où la clé AES était dans une variable d'environnement non chiffrée sur le même serveur que la base de données. Autant dire qu'un attaquant qui compromet le serveur a les données et la clé. Zéro pointé.

Trois règles simples :

• Utilisez un KMS (Key Management Service) ou un HSM (Hardware Security Module) pour stocker les clés. Jamais dans votre code.
• Faites une rotation des clés régulière. Tous les 6 à 12 mois est un bon rythme pour la plupart des PME.
• Prévoyez une procédure de récupération. Perdre une clé, c'est perdre les données. Définitivement.

Chiffrement de bout en bout et chiffrement homomorphe : où on en est

Le chiffrement de bout en bout (E2EE) garantit que seuls l'émetteur et le destinataire peuvent lire un message. Les serveurs intermédiaires ne voient que du bruit. C'est ce que propose Signal depuis des années, et c'est devenu un argument commercial chez plusieurs messageries d'entreprise.

Le chiffrement homomorphe, lui, permet de calculer sur des données chiffrées sans avoir à les déchiffrer. Puissant sur le papier. En pratique, encore lent et coûteux pour un déploiement à grande échelle en 2026. Je le mentionne parce qu'on me pose la question, mais je ne le recommande pas encore à une PME qui veut juste protéger ses données clients.

Les limites à connaître avant de crier victoire

Chiffrer ne rend pas invulnérable. Trois cas où ça ne sauve pas :

• Si l'endpoint est compromis. Chiffrer la base ne sert à rien si l'attaquant est déjà dans votre application et peut lire les données déchiffrées en mémoire.
• Si les accès ne sont pas cloisonnés. Une clé partagée par 47 personnes, c'est comme un mot de passe unique. Ça finit toujours mal.
• Si vous chiffrez sans journaliser. Comment prouver au régulateur que seules les bonnes personnes ont eu accès, sans logs ?

Et un dernier point, souvent négligé : crypter ou chiffrer ? En français, « crypter » est un anglicisme (to encrypt). Le terme correct est « chiffrer ». Dire « crypter » pour « chiffrer » revient à dire « crypter » pour « crypter » — ce qui veut déjà dire autre chose. Bref, dites « chiffrer », vous passerez pour quelqu'un qui sait de quoi il parle.

Le chiffrement n'est pas une baguette magique. C'est une brique. Une brique indispensable quand on manipule des données personnelles, et une brique qui devient absurde sans gestion rigoureuse des clés, sans contrôle des accès, sans documentation. Vous pouvez chiffrer parfaitement et rester non conforme. Vous pouvez aussi ne pas chiffrer et perdre beaucoup plus qu'une amende le jour où ça arrive.

La bonne question n'est pas « quel algorithme est le plus fort ? ». C'est : « si mes données fuitent demain, qu'est-ce que l'attaquant peut réellement en faire ? ». Si la réponse est « rien, elles sont illisibles », vous avez fait votre travail. Si la réponse est « il a les noms, les IBAN et les adresses de 14 000 personnes », vous savez ce qu'il vous reste à faire.