Chiffrer les données de vos clients quand vous éditez un SaaS régulé

Pourquoi un éditeur SaaS doit chiffrer les champs sensibles de ses clients ?

Un éditeur SaaS B2B est le sous-traitant de ses clients au sens de l'article 28 du RGPD. Dès qu'un client régulé, banque, assureur ou groupe de santé, évalue votre solution, son RSSI vous adresse un questionnaire de sécurité où le chiffrement au repos est une ligne attendue. Le chiffrer et le prouver débloque la signature. C'est le sujet, pas la peur d'une fuite.

L'article 32 du RGPD, publié par l'Union européenne (règlement 2016/679), cite explicitement le chiffrement parmi les mesures techniques appropriées pour sécuriser un traitement. La CNIL le reprend dans sa fiche « Sécurité : chiffrer les données », qui en fait un standard de fait attendu de tout responsable et de tout sous-traitant. Ne pas chiffrer des données sensibles est aujourd'hui traité comme une sécurité inadéquate par les autorités.

La délibération SAN-2026-001 de la CNIL du 8 janvier 2026, publiée sur Légifrance, l'illustre concrètement : Free Mobile a été sanctionné de 27 millions d'euros après qu'un outil métier a renvoyé l'IBAN complet de clients, sur le fondement notamment de l'article 32 du RGPD. Pour un éditeur, le message est direct : la donnée sensible d'un client mal protégée devient sa responsabilité, et la vôtre en tant que sous-traitant.

Faut-il attendre NIS2 pour chiffrer ?

Non. NIS2 n'est pas transposée en France : le projet de loi Résilience reste bloqué au Parlement, et la Commission européenne a saisi la Cour de justice de l'Union le 8 juillet 2026 pour défaut de transposition. Ne construisez donc pas votre argumentaire commercial sur une obligation NIS2 « applicable » aujourd'hui. Appuyez-vous sur le RGPD Art. 32, qui est en vigueur.

La directive NIS2 (UE 2022/2555) devait être transposée avant le 17 octobre 2024. Elle ne l'a pas été, notamment à cause de l'article 16 bis sur le chiffrement, qui oppose parlementaires et services de renseignement. La saisine de la CJUE du 8 juillet 2026, documentée par la Commission européenne, confirme que le texte français n'est pas voté et que son examen est repoussé à la rentrée parlementaire au plus tôt.

Le raisonnement pratique tient en une phrase : le chiffrement que le RGPD attend déjà de vous est le même que celui que NIS2 formalisera. En chiffrant maintenant pour l'article 32, vous n'anticipez pas un risque hypothétique, vous répondez à une obligation en vigueur et vous prenez de l'avance sur ce qui arrive. NIS2 arrive, anticipez, mais ne la présentez à vos clients ni comme votée ni comme applicable.

AES-256-GCM : quel algorithme choisir et sur quelle base ?

AES-256-GCM est le choix par défaut pour chiffrer des champs applicatifs. Il combine confidentialité et intégrité dans un même mécanisme (chiffrement authentifié, AEAD), ce qui protège la donnée et détecte toute altération. Il figure parmi les mécanismes recommandés par l'ANSSI et le NIST, les deux références qu'un auditeur reconnaît sans discussion.

L'ANSSI recommande AES-256-GCM dans son guide des mécanismes cryptographiques PG-083, dont la version 3.00 est datée du 20 mars 2026. Le NIST spécifie le mode Galois/Counter Mode dans sa publication SP 800-38D. Citer ces deux textes, nommés et datés, dans un questionnaire de sécurité vaut mieux qu'une affirmation générale : c'est ce qu'un RSSI vérifie.

Un point de vigilance porte sur les usages. AES-256-GCM est adapté au chiffrement de champs et d'échanges d'API. Le chiffrement de disque relève d'un autre mode. La question de votre client régulé n'est pas « chiffrez-vous ? » mais « quel algorithme, quelle taille de clé, et comment gérez-vous les clés ? ». C'est cette précision qui réduit le nombre d'allers-retours et raccourcit le cycle de vente.

Chiffrement de disque ou chiffrement applicatif : lequel un auditeur regarde-t-il ?

Le chiffrement de disque protège contre le vol physique d'un serveur. Il ne protège pas la donnée quand l'application tourne : un accès applicatif, une requête SQL ou une fuite via un outil métier voient la donnée en clair. Un auditeur de client régulé regarde le chiffrement applicatif, au niveau du champ, parce que c'est lui qui limite l'exposition en cas d'incident.

Le cas Free illustre la limite du chiffrement de disque : la base était hébergée sur une infrastructure sérieuse, mais un outil métier renvoyait l'IBAN en clair. Le chiffrement au niveau du champ, avec des clés distinctes de l'application, aurait réduit l'exposition. C'est la différence entre « nos disques sont chiffrés » et « les IBAN de vos utilisateurs sont chiffrés individuellement ».

Pour un éditeur SaaS, le bon périmètre est rarement toute la base. C'est l'ensemble des champs réellement sensibles : identifiants de santé, IBAN, données d'authentification, secrets métier. Chiffrer ces champs applicativement, plutôt que le disque entier, donne une réponse précise à un questionnaire de sécurité et évite le coût d'un chiffrement indifférencié qui pénalise les performances sans améliorer la preuve.

Comment structurer ses clés : l'architecture DEK/KEK ?

L'architecture DEK/KEK, ou envelope encryption, sépare la clé qui chiffre la donnée de la clé qui protège cette première clé. Chaque donnée est chiffrée par une clé de données (DEK). Chaque DEK est chiffrée par une clé de chiffrement de clés (KEK) qui, elle, ne quitte jamais son coffre. Une DEK compromise n'expose que la donnée associée, jamais l'ensemble du système.

Concrètement : une DEK aléatoire est générée par opération, la donnée est chiffrée avec, puis la DEK est wrappée par la KEK. Le NIST décrit cette hiérarchie dans sa publication SP 800-57 Part 1 sur la gestion des clés, qui recommande aussi des périodes d'usage bornées et une rotation régulière. C'est l'architecture que les hyperscalers et les KMS de référence appliquent, et celle qu'un auditeur attend d'un dossier structuré.

Cette structure adresse trois exigences d'un même geste : la confidentialité (la donnée est chiffrée), la limitation d'impact (le rayon d'une compromission est borné), et la traçabilité (chaque opération de chiffrement et chaque accès à une clé peut être journalisé). C'est ce dernier point, la preuve, qui distingue une architecture chiffrée d'une architecture chiffrée et démontrable.

Où stocker la KEK : faut-il un HSM matériel ?

La KEK doit résider dans un coffre à clés qui ne la laisse jamais sortir en clair, un HSM ou un KMS. La question du HSM matériel certifié FIPS 140-2 se pose surtout pour les clients les plus exigeants. Beaucoup d'éditeurs démarrent avec un HSM logiciel via l'interface PKCS#11, ce qui reste une réponse recevable tant qu'elle est décrite honnêtement à l'auditeur.

Un HSM matériel isole les clés dans un composant physique inviolable. Un HSM logiciel offre la même interface PKCS#11 et la même logique de wrapping, sans le composant matériel. Le NIST distingue les niveaux de sécurité dans sa norme FIPS 140-3, alignée sur l'ISO/IEC 19790. Pour un dossier de conformité, ce qui compte est de nommer précisément ce que vous utilisez et votre trajectoire, pas de sur-déclarer une capacité que vous n'avez pas.

MAFATE est transparent sur ce point : son coffre à clés repose aujourd'hui sur un HSM logiciel PKCS#11, avec une migration vers un HSM matériel FIPS 140-2 planifiée. Sur-déclarer un HSM matériel qu'on ne détient pas est le genre d'imprécision qu'un auditeur détecte et qui coûte la confiance d'un client régulé. La bonne pratique, côté éditeur comme côté fournisseur, est de décrire l'existant et la roadmap.

Comment prouver son chiffrement dans un questionnaire de sécurité ?

En pré-constituant le dossier. Un client régulé attend quatre preuves : un DPA conforme à l'article 28 du RGPD, la localisation de l'hébergement, la documentation des mesures de l'article 32 (algorithme, gestion des clés, contrôle d'accès), et la liste des sous-traitants. Répondre par renvoi documentaire, plutôt que question par question, transforme un audit exhaustif en simple validation et raccourcit le cycle de vente.

La partie chiffrement de ces questionnaires se répond avec trois éléments : l'algorithme et sa source (AES-256-GCM, ANSSI PG-083, NIST SP 800-38D), l'architecture de clés (DEK/KEK, rotation, coffre), et un journal d'audit qui montre que les opérations ont réellement eu lieu. Un rapport de conformité généré depuis ces journaux contribue au dossier. Il ne constitue pas un certificat, et il ne faut pas le présenter comme tel.

C'est la logique de réduction de périmètre : plus vous documentez en amont, moins votre client a de questions ouvertes, et moins son propre auditeur a de zones à explorer chez vous. Le chiffrement applicatif bien structuré et bien journalisé est un des leviers les plus directs pour raccourcir la due diligence sécurité d'un grand compte, et donc pour signer plus vite.

Comment un éditeur intègre-t-il le chiffrement sans construire d'infrastructure ?

En s'appuyant sur une brique de chiffrement en tant que service (EaaS) plutôt qu'en montant son propre KMS et son propre HSM. Un éditeur SaaS de 8 à 40 personnes n'a ni le temps ni l'intérêt de bâtir une infrastructure de gestion de clés. Il a besoin d'une API qui chiffre les champs sensibles, garde les clés dans un coffre, et produit les preuves qui alimentent le dossier de conformité de ses clients.

C'est le rôle d'une plateforme comme MAFATE, pensée pour l'éditeur SaaS régulé : une API et des SDK pour chiffrer des champs applicatifs en AES-256-GCM avec une architecture DEK/KEK, un KMS pour gérer les versions et la rotation des clés, un journal d'audit chaîné, et des rapports de conformité RGPD Art. 32 exportables. L'architecture de sécurité est opérée en France par UNIVILE SAS, opérateur français non soumis au CLOUD Act, ce qui répond à la question de juridiction que posent les clients régulés.

La question de qualification reste la même pour tout éditeur : avez-vous un contrat que vous perdez ou retardez parce qu'on vous réclame une preuve de chiffrement ? Si oui, l'enjeu n'est pas d'acheter des clés, c'est de gagner le temps de signature. C'est ce que la documentation MAFATE détaille côté gestion des clés, et ce dont un ingénieur MAFATE peut discuter sur votre cas précis.

Vous montez un dossier de conformité et vous voulez cadrer le périmètre de chiffrement avec vos exigences client : parler à un ingénieur MAFATE.