Chiffrement des données SaaS : le guide opérationnel pour les responsables IT

Activez le chiffrement en transit et au repos par défaut sur toutes vos applications SaaS, sans exception. Pour les données réellement sensibles, gardez la gestion des clés sous votre contrôle plutôt que de la laisser entièrement au fournisseur. Classez d’abord vos données : le chiffrement côté client ne se justifie que lorsque la confidentialité prime sur la richesse fonctionnelle, car il casse souvent la recherche et l’automatisation.

En bref:

• Le chiffrement en transit doit couvrir tous les flux de données, y compris API internes et échanges entre microservices, avec une vérification qu’aucun endpoint ne confirme une connexion en clair.
• Le chiffrement au repos doit s’appliquer à toutes les données stockées, notamment bases, sauvegardes et journaux, en activant le chiffrement natif ou en exigeant des fournisseurs qu’ils le proposent.
• La gestion des clés doit privilégier la souveraineté en utilisant des solutions comme BYOK ou EKM, tout en respectant le niveau FIPS 140‑2 niveau 3 pour la sécurité.
• La cryptographie homomorphe ou MPC n’est pas encore adaptée pour des usages SaaS classiques, étant limitée en performance et réservée à des cas non critiques en temps réel.
• La maîtrise des clés par le client reste essentielle pour respecter le RGPD et assurer que le fournisseur ne puisse pas accéder aux données en clair, notamment en dehors de l’Union européenne.

Table des matières

• Principes essentiels : qu’est-ce que le chiffrement et quels types existent
• Où appliquer le chiffrement dans une architecture SaaS
• Gestion des clés : BYOK, CMEK, EKM, HSM et leurs compromis
• Approches pratiques pour mettre en œuvre le chiffrement dans un projet SaaS
• Techniques avancées : FHE et MPC, quelle maturité en 2026
• Conformité et responsabilité : ce que rappelle la CNIL
• Point de vue : les erreurs les plus fréquentes en matière de chiffrement SaaS
• Une autre approche pour les sociétés de domiciliation : centraliser conformité et audit avec Adryo
• Sources
• Questions fréquentes

Principes essentiels : qu’est-ce que le chiffrement et quels types existent

Le chiffrement transforme une information lisible en données illisibles sans une clé. Deux familles dominent : le chiffrement symétrique, où la même clé chiffre et déchiffre (rapide, adapté aux gros volumes), et le chiffrement asymétrique, qui repose sur une paire clé publique/clé privée, plus lent mais utile pour l’échange de clés ou les signatures. Le hachage, lui, ne se déchiffre pas : il sert à vérifier l’intégrité d’un fichier ou à stocker un mot de passe sans jamais le révéler.

Pour un responsable IT qui pilote une architecture SaaS, trois périmètres comptent réellement :

• Chiffrement en transit : protège les données qui circulent entre le navigateur, l’application et les serveurs, typiquement via TLS.
• Chiffrement au repos : protège les données stockées sur disque, dans les bases de données et les sauvegardes.
• Chiffrement applicatif ou côté client : la donnée est chiffrée avant même d’atteindre le fournisseur, qui ne détient jamais la clé.

Cette distinction n’est pas théorique. Un chiffrement au repos géré par le fournisseur protège contre le vol physique d’un disque, mais n’empêche pas ce même fournisseur de lire les données en clair pour les besoins de son service. Un chiffrement côté client empêche cet accès, mais complique l’indexation, la recherche plein texte et certaines automatisations qui ont besoin de lire la donnée pour fonctionner. Le bon niveau dépend de ce que vous protégez, pas d’une règle universelle.

Où appliquer le chiffrement dans une architecture SaaS

Une architecture SaaS comporte plusieurs couches, et chacune appelle un traitement différent. Le chiffrement en transit doit couvrir tous les flux, pas seulement le trafic principal vers l’utilisateur final : API internes, appels entre microservices, exports vers des partenaires. Un test simple consiste à vérifier qu’aucun endpoint n’accepte de connexion en clair et que les certificats sont renouvelés automatiquement.

Le chiffrement au repos, quant à lui, doit s’étendre au delà de la base de données principale :

• Bases de données : chiffrement natif activé, souvent par défaut chez les grands fournisseurs cloud.
• Sauvegardes : trop souvent oubliées, alors qu’elles contiennent les mêmes données sensibles que la production.
• Journaux applicatifs : peuvent contenir des identifiants ou des fragments de données personnelles par erreur de configuration.

Le chiffrement applicatif ou côté client reste l’option la plus protectrice pour la confidentialité, mais elle a un coût réel : recherche côté serveur désactivée ou limitée, automatisations qui ne peuvent plus lire la donnée, complexité accrue pour les intégrations tierces. Réservez-le aux données dont la sensibilité justifie ce compromis, par exemple des informations contractuelles ou des données réglementées.

Gestion des clés : BYOK, CMEK, EKM, HSM et leurs compromis

La gestion des clés détermine qui contrôle réellement l’accès aux données, bien plus que le chiffrement lui-même. Plusieurs modèles coexistent chez les fournisseurs cloud actuels :

• CMEK (clés gérées par le client dans l’infrastructure du fournisseur) : le client garde un contrôle partiel sans opérer l’infrastructure de clés.
• BYOK (apport de ses propres clés) : le client importe ses clés dans le service du fournisseur, ce qui renforce la souveraineté sans éliminer la dépendance opérationnelle.
• EKM (gestion externe des clés) : les clés restent hébergées en dehors de l’environnement du fournisseur, avec des mécanismes de validation des demandes d’accès, une approche que documente Google Cloud sur la gestion des clés.

Le choix BYOK augmente la souveraineté, mais transfère aussi la responsabilité opérationnelle vers le client : sauvegarde des clés, rotation, procédure de récupération en cas d’incident, comme le rappelle la documentation Microsoft sur la gestion des clés. Un article technique détaille cette bascule de responsabilité dans le fonctionnement du BYOK.

Le FIPS 140‑2 niveau 3 est recommandé pour le stockage des clés racines, selon Microsoft, ce qui signifie qu’une clé racine mal protégée compromet toute la chaîne de confiance construite au-dessus.

Avant de signer avec un fournisseur, demandez concrètement :

• Les journaux d’accès aux clés sont-ils exportables et consultables en continu ?
• La rotation des clés est-elle automatisée ou manuelle ?
• Les environnements de production et de test utilisent-ils des clés strictement séparées ?

Comme le souligne IBM sur la gestion des clés, la gestion des clés reste souvent le point faible opérationnel : sans HSM ni séparation stricte des fonctions, un simple KMS n’apporte pas la souveraineté juridique espérée.

Approches pratiques pour mettre en œuvre le chiffrement dans un projet SaaS

Un déploiement réussi suit un ordre logique plutôt qu’un big bang sur l’ensemble du système.

1. Classifier les données selon leur sensibilité réelle, pas selon leur volume : données financières, données de santé ou informations d’identification exigent un niveau de protection différent d’un simple journal d’usage.
2. Lancer un pilote restreint sur un périmètre limité, par exemple un seul module ou une seule table sensible, pour mesurer l’impact sur la recherche et les performances.
3. Étendre progressivement aux autres périmètres identifiés lors de la classification, en documentant chaque écart de fonctionnalité observé.
4. Auditer régulièrement les accès aux clés, la rotation effective et la cohérence entre l’environnement de production et les engagements contractuels du fournisseur.

Conseil de pro : testez systématiquement une procédure de récupération de clé avant la mise en production, jamais après un incident réel.

Trois documents doivent sortir de ce projet, pas seulement du code. Une matrice de responsabilité qui précise qui, entre vous et le fournisseur, gère quoi sur le chiffrement. Des clauses contractuelles qui couvrent l’accès aux clés, la localisation des données et les modalités d’audit. Et des procédures écrites de rotation et de sauvegarde des clés, testées au moins une fois avant d’être considérées comme opérationnelles.

Techniques avancées : FHE et MPC, quelle maturité en 2026

Le chiffrement homomorphe (FHE) permet des calculs directement sur des données chiffrées, sans jamais les déchiffrer. Le calcul multipartite (MPC) répartit un calcul entre plusieurs parties, chacune ne voyant qu’un fragment de l’information. Ces deux approches sont séduisantes sur le papier, notamment pour un SaaS qui traiterait des données sensibles sans jamais y avoir accès en clair.

Dans les faits, le dossier LINC de la CNIL sur la cryptographie situe leur maturité en 2026 comme encore limitée pour des SaaS métiers complexes, en raison des coûts de calcul et de l’impact sur les performances.

Concrètement, cela signifie :

• Éviter les usages temps réel : la latence induite par le FHE ou le MPC reste incompatible avec une expérience utilisateur SaaS classique.
• Réserver les POC à des cas non critiques en performance : analyses réglementaires en différé, mutualisation de calculs entre organisations, secteurs très régulés.
• Traiter ces technologies comme un pari à moyen terme, pas comme une réponse aux besoins de chiffrement du quotidien.

Conformité et responsabilité : ce que rappelle la CNIL

Sous le RGPD, la responsabilité de la protection des données reste celle du client, quel que soit le niveau de chiffrement proposé par le fournisseur SaaS. La CNIL rappelle dans ses recommandations sur le chiffrement cloud que le chiffrement côté client, avec des clés gérées par le client, reste la seule approche qui empêche formellement le fournisseur d’accéder aux données en clair.

Cette exigence pèse particulièrement sur les transferts hors Union européenne, où les garanties contractuelles et techniques doivent se renforcer mutuellement plutôt que reposer sur la seule confiance envers le prestataire.

Avant de signer, vérifiez concrètement :

• L’accès aux clés : le fournisseur peut-il techniquement déchiffrer vos données, même en théorie ?
• La localisation des données et des clés : correspond-elle aux engagements contractuels annoncés ?
• Les certifications disponibles : rapports SOC, certifications ISO ou attestations d’hébergement à demander avant la signature.

Point de vue : les erreurs les plus fréquentes en matière de chiffrement SaaS

L’erreur la plus répandue reste de faire confiance au chiffrement du fournisseur sans jamais vérifier qui détient réellement les clés. Un chiffrement au repos activé par défaut donne un faux sentiment de sécurité s’il ne s’accompagne pas d’une gestion des clés vérifiable. Mieux vaut un POC modeste avec rotation automatisée et traçabilité complète qu’un déploiement massif documenté après coup.

— Aimen

Une autre approche pour les sociétés de domiciliation : centraliser conformité et audit avec Adryo

Le chiffrement des données ne suffit pas à lui seul si votre outil de gestion reste un empilement d’Excel, de courrier papier, d’un logiciel de facturation et d’un outil de signature séparés. Pour les sociétés de domiciliation agréées, certaines plateformes SaaS réunissent en un seul outil le CRM des entreprises domiciliées, la conformité LCB-FT et une piste d’audit horodatée exportable.

Les données peuvent être hébergées en France, dans le cadre d’une conformité RGPD, ce qui simplifie les vérifications contractuelles évoquées plus haut. L’objectif : sécuriser l’agrément préfectoral avant chaque contrôle, sans ressaisie manuelle entre plusieurs outils.

Consultez la page produit Adryo pour voir comment la plateforme structure conformité, contrats et facturation en un seul endroit.

Sources

• Les pratiques de chiffrement dans l’informatique en nuage (cloud) public | CNIL
• Key management - Azure security fundamentals | Microsoft Learn
• Les clés pour comprendre la cryptographie — dossier LINC | CNIL
• Qu’est‑ce que la gestion des clés ? | IBM

Questions fréquentes

Qu’est-ce qu’un logiciel SaaS, en quelques mots ?

Un SaaS est une application accessible en ligne, hébergée et maintenue par un fournisseur, sans installation locale par l’utilisateur. Les outils de messagerie, de CRM ou de facturation en ligne en sont des exemples courants.

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

Le chiffrement transforme une information lisible en données illisibles sans une clé spécifique, protégeant ainsi son contenu en cas d’accès non autorisé.

Quels sont les principaux types de chiffrement utilisés en SaaS ?

Le chiffrement symétrique utilise une seule clé pour chiffrer et déchiffrer, tandis que le chiffrement asymétrique repose sur une paire de clés publique et privée. En environnement SaaS, on retrouve aussi le hachage pour vérifier l’intégrité des données, souvent combiné aux deux approches précédentes.

Quelle différence entre SaaS et cloud en général ?

Le cloud désigne l’ensemble des ressources informatiques accessibles à distance, incluant le stockage, le calcul et les réseaux. Le SaaS est une catégorie précise du cloud : une application prête à l’emploi, alors que d’autres catégories comme l’IaaS ou le PaaS fournissent une infrastructure ou une plateforme à configurer soi-même.

Qui doit gérer les clés de chiffrement dans une relation avec un fournisseur SaaS ?

Cela dépend de la sensibilité des données et du modèle choisi : CMEK, BYOK ou EKM répartissent différemment le contrôle entre le client et le fournisseur. Pour les données les plus sensibles, la CNIL recommande que le client garde la maîtrise des clés afin d’empêcher tout accès du prestataire aux données en clair.