Page mise à jour le
La réponse courte
L'article 32 du RGPD demande au responsable et au sous-traitant des mesures appropriées, compte tenu de l'état des connaissances, des coûts, de la nature du traitement et des risques. Il cite, parmi les mesures à envisager, « la pseudonymisation et le chiffrement des données à caractère personnel ». Ce n'est pas une obligation universelle de tout chiffrer. C'est une mesure à caler sur le risque. L'ANSSI, dans son guide d'hygiène informatique, en fait une pratique de base pour les données sensibles et les sauvegardes. Pour une PME, le geste utile n'est pas d'acheter un produit « zero-knowledge » par réflexe : c'est de chiffrer le transit (HTTPS, pas de FTP en clair), chiffrer les disques et les sauvegardes, et poser la question des clés — qui peut déchiffrer, en quelles circonstances, y compris le support.
Trois couches, trois questions
En transit : un site, une API, une messagerie, un transfert de fichier, sans TLS, c'est de la donnée en clair sur le réseau. C'est le plus simple à corriger, et c'est encore trop fréquent (export FTP, pièce jointe non chiffrée, lien d'un cloud mal paramétré). Au repos : disques des serveurs, disques des portables, bases. Un portable volé sans chiffrement de disque est un incident classique, pas une hypothèse. En sauvegarde : une copie non chiffrée, stockée « pour plus tard » sur un disque externe ou un bucket, est souvent plus riche et moins surveillée que la production. L'ANSSI insiste sur ce point : une sauvegarde est une cible. Chiffrer les trois couches sans savoir qui détient les clés, c'est déléguer le déchiffrement au premier administrateur venu — y compris chez le prestataire.
Les clés : le vrai sujet, pas l'algorithme
Une PME n'a pas à choisir entre des algorithmes : AES et TLS modernes, tels que recommandés par l'ANSSI, suffisent, et les outils courants les embarquent. Le sujet est opérationnel. Si l'hébergeur détient les clés, il peut lire, et un droit d'accès tiers s'exerce sur du clair. Si vous détenez les clés (chiffrement côté client, coffre, HSM, option « customer managed keys »), le prestataire administre sans lire — et vous ne devez pas les perdre, parce qu'une clé perdue, c'est une donnée détruite. C'est un trade-off, pas une vertu. Pour un site vitrine, le TLS et des sauvegardes chiffrées chez l'hébergeur suffisent largement. Pour un CRM, des dossiers clients, des prompts d'IA, la question des clés rejoint celle du secret des affaires et de l'article 28 : un sous-traitant qui lit tout en clair n'a de « chiffrement » que le mot.
Ce que le chiffrement ne fait pas
Il ne remplace pas les droits d'accès. Un salarié habilité voit du clair, c'est le but. Il ne remplace pas la minimisation : chiffrer des données que vous n'auriez pas dû collecter n'en fait pas un traitement licite. Il ne rend pas anonyme : une donnée chiffrée dont vous avez la clé reste une donnée personnelle. Il ne dispense pas de notifier une violation si les clés ont pu partir avec les disques. L'article 34, paragraphe 3, point a), prévoit que la notification aux personnes n'est pas requise si les données étaient rendues incompréhensibles (chiffrement) et que les clés n'ont pas été compromises. C'est une raison de plus de chiffrer les sauvegardes et les portables, pas une raison de croire qu'un incident chiffré n'est plus un incident.
IA, prompts, et disques : ne pas tout mélanger
Envoyer un prompt à un modèle, c'est un transit. S'il est en clair, chez un fournisseur qui journalise en clair, le chiffrement de votre disque local ne sert plus à rien pour cette donnée-là. Le bon ordre est : d'abord, ce qui ne sort pas ; ensuite, ce qui sort sous TLS vers un sous-traitant borné ; ensuite, le chiffrement au repos chez vous et chez lui. Un outil « chiffré de bout en bout » dont le modèle doit lire le prompt pour répondre n'est pas de bout en bout au sens messagerie : le modèle voit le clair, par construction. Le dire évite d'acheter une promesse. Le self-hébergement, lui, change qui a les clés, et change le coût d'attention : c'est un autre article de ce site, pas celui-ci.
À vérifier chez vous
Ce que vous pouvez contrôler vous-même
Des points vérifiables sans expertise juridique. Si l'un d'eux coince, c'est celui-là qu'il faut apporter à votre conseil.
- HTTPS partout, plus de transfert de fichiers en clair.
- Chiffrement de disque sur les portables, et des sauvegardes.
- Demander qui détient les clés chez l'hébergeur et chez le fournisseur d'IA.
- Ne pas confondre chiffrement, anonymisation, et minimisation.
- Tester qu'une sauvegarde chiffrée se restaure — avec la clé, et sans la clé (ça doit échouer).
Sources
Chaque affirmation de cette page renvoie au texte qui fait foi. En cas d'écart entre cette page et la source, c'est la source qui a raison.
- EUR-Lex — règlement (UE) 2016/679 (RGPD) (nouvel onglet)
Articles 5, 6 (base légale), 9, 13-14, 22, 24, 28 (sous-traitant), 32, 35 (AIPD), chapitre V (transferts).
- ANSSI — guide d'hygiène informatique (nouvel onglet)
Mesures concrètes : sauvegardes testées, chiffrement, journalisation, mises à jour. Référentiel de bonnes pratiques, pas une obligation légale autonome.
- CNIL — transférer des données hors de l'UE (nouvel onglet)
Chapitre V du RGPD : décision d'adéquation, clauses types, garanties appropriées. La localisation du serveur n'épuise pas la question.
- CNIL — la sécurité des données personnelles (guide) (nouvel onglet)
Mesures organisationnelles et techniques, dont le chiffrement, calées sur le risque. Droit souple qui explicite l'article 32.
Vos questions
Le RGPD m'oblige-t-il à tout chiffrer ?
Non. L'article 32 liste le chiffrement parmi les mesures à envisager, au regard du risque. Un fichier de newsletter n'appelle pas le même niveau qu'un dossier de santé ou une base de paie. En pratique, le chiffrement de transit est devenu le minimum de l'état des connaissances, et le chiffrement des portables et des sauvegardes est une mesure de bon sens que l'ANSSI range dans l'hygiène de base. « Tout chiffrer », y compris des données que le métier doit lire en permanence, sans gérer les clés, crée plus de pannes que de sécurité. On chiffre ce qui, ouvert, coûte cher.
Un cloud « chiffré » veut-il dire que le prestataire ne peut pas lire ?
Souvent, non. Le chiffrement côté serveur, avec des clés gérées par l'hébergeur, protège contre un vol de disque, pas contre l'administrateur, ni contre une réquisition qui s'adresse à lui. Pour que le prestataire ne lise pas, il faut un chiffrement dont vous détenez les clés, ou une architecture documentée comme telle. C'est plus contraignant (perte de clé = perte de donnée, fonctions de recherche limitées). C'est un choix, pas un label. La brochure qui dit « chiffré » sans dire qui a les clés ne dit rien.
Dois-je chiffrer les prompts envoyés à un modèle ?
Le canal doit être chiffré (TLS). Le contenu, lui, doit être lu par le modèle pour servir : un prompt chiffré de bout en bout que le modèle ne peut pas déchiffrer ne produit pas de réponse. Ce qu'on peut faire : ne pas envoyer ce qui ne doit pas sortir ; borner la rétention des logs de prompts chez le fournisseur ; chiffrer vos propres journaux au repos. Confondre ces trois mesures avec un « E2E » de messagerie, c'est acheter un mot. La question utile reste : ce prompt a-t-il le droit de sortir, et qui le conserve.
Une idée en tête ?
Réservez un rendez-vous ou écrivez-nous — réponse sous 24 h.