RGPD et sécurité applicative : ce que les éditeurs SaaS doivent savoir

Le RGPD est souvent traité comme un sujet juridique, confié à un cabinet extérieur qui produit une politique de confidentialité et un registre. Une partie substantielle du texte porte pourtant sur des décisions techniques, prises dans le code, par l’équipe de développement. Ce qui suit décrit ces points d’articulation, sans se substituer à un conseil juridique.

Votre rôle : presque toujours sous-traitant

Un éditeur SaaS traite des données personnelles pour le compte de ses clients : il est sous-traitant au sens de l’article 28, le client étant responsable de traitement. Cette qualification a trois conséquences directes.

Vous n’agissez que sur instruction documentée du client, formalisée par un accord de sous-traitance (DPA). Vous devez pouvoir démontrer les garanties que vous apportez. Et vous restez soumis à des obligations propres, notamment de sécurité, indépendamment de ce que fait votre client.

Attention à la double casquette : sur les données de vos propres prospects, salariés et utilisateurs de votre site, vous êtes responsable de traitement. Les deux registres coexistent.

L’article 32 : ce que « mesures appropriées » signifie techniquement

L’article 32 impose des mesures techniques et organisationnelles adaptées au risque, et cite explicitement quatre familles.

La pseudonymisation et le chiffrement. Ni l’un ni l’autre n’est obligatoire en toutes circonstances ; leur absence sur des données sensibles doit être justifiée. Le chiffrement au repos du volume de stockage est un minimum attendu, mais il ne protège que contre un vol de support physique : il n’a aucun effet contre une faille applicative. Pour les catégories les plus sensibles, un chiffrement au niveau applicatif, avec des clés gérées séparément, change réellement le profil de risque.

La confidentialité, l’intégrité, la disponibilité et la résilience. C’est là que se retrouvent le contrôle d’accès, la séparation entre clients, la journalisation, la gestion des secrets et la robustesse de l’architecture.

La restauration en temps utile. Les sauvegardes ne suffisent pas : il faut avoir vérifié qu’elles se restaurent, et connaître le délai. Une sauvegarde jamais testée est une hypothèse, pas une mesure.

L’évaluation régulière de l’efficacité des mesures. C’est la base réglementaire directe des audits et tests d’intrusion périodiques. Le texte n’impose pas de fréquence ; il impose de pouvoir démontrer un processus.

Les décisions de conception qui découlent de l’article 25

L’article 25 impose la protection des données « dès la conception » et « par défaut ». Traduit en pratique, cela se joue sur quatre décisions concrètes.

La minimisation. Collecter uniquement ce qui est nécessaire. Un formulaire qui demande une date de naissance sans usage identifié, un enregistrement d’événements qui stocke l’intégralité des corps de requête, une table qui conserve l’adresse IP de chaque action indéfiniment : chacun est un écart, et chacun augmente l’impact d’une éventuelle fuite.

Les paramètres par défaut. Un nouvel espace de travail doit démarrer dans sa configuration la plus protectrice : partage public désactivé, visibilité restreinte, journalisation activée. L’ouverture doit résulter d’un choix explicite du client.

La durée de conservation. Techniquement, cela signifie des mécanismes de purge automatique, pour les données applicatives comme pour les journaux, les sauvegardes, les exports générés, les caches et les corbeilles. C’est le point le plus souvent absent des architectures : la suppression est presque toujours logique, jamais réelle.

La granularité des droits. Un modèle de permissions fin sert directement le principe de minimisation d’accès à l’intérieur d’une organisation cliente.

Les droits des personnes, vus du code

Trois droits impliquent des développements réels, et le sous-traitant doit permettre au responsable de traitement de les honorer.

L’accès et la portabilité supposent d’exporter, dans un format structuré et lisible par machine, l’ensemble des données relatives à une personne. Sur une architecture où les données d’un utilisateur sont réparties entre une base principale, un entrepôt analytique, un outil de support et un service d’e-mailing, l’exercice est loin d’être trivial.

L’effacement exige une suppression effective, pas un simple drapeau. Il faut identifier toutes les copies : réplicas, sauvegardes, index de recherche, files de messages, journaux, outils tiers. Une position défendable consiste à supprimer immédiatement dans les systèmes actifs et à laisser les sauvegardes expirer selon un cycle documenté et court.

La rectification doit se propager aux systèmes en aval, ce qui suppose de savoir où les données ont été copiées.

La notification de violation : 72 heures, et une contrainte technique

En cas de violation, le responsable de traitement dispose de 72 heures pour notifier l’autorité de contrôle. En tant que sous-traitant, vous devez alerter votre client « dans les meilleurs délais » ; les DPA prévoient couramment 24 à 48 heures.

Cette contrainte est d’abord technique. Pour notifier, il faut être capable de répondre à trois questions : quelles données ont été concernées, combien de personnes, et sur quelle période. Sans journalisation adéquate (traces d’accès aux données, conservées suffisamment longtemps et exploitables rapidement), ces réponses sont hors de portée. Beaucoup d’organisations découvrent au pire moment que leurs journaux sont conservés sept jours, ou n’enregistrent pas les lectures.

Concrètement : journaliser les accès aux données personnelles, conserver ces traces plusieurs mois, les stocker hors de portée d’un attaquant ayant compromis l’application, et savoir les interroger. C’est un chantier d’ingénierie, pas de rédaction juridique.

Les transferts hors Union européenne

Si votre plateforme s’appuie sur des services situés hors UE, ou sur des entreprises soumises à des législations extraterritoriales, ces transferts doivent être identifiés, encadrés et documentés dans votre DPA.

Techniquement, cela commence par un inventaire honnête des flux sortants : services d’e-mailing transactionnel, outils d’analyse, supervision d’erreurs, support client, hébergement de fichiers, services d’inférence. La supervision d’erreurs est un cas classique : une trace d’exception contient fréquemment des données personnelles envoyées vers un service tiers, sans que personne ne l’ait décidé.

Ce que vos clients vont vous demander

En pratique, un client grand compte demandera : votre DPA, la liste de vos sous-traitants ultérieurs, la localisation des données, vos durées de conservation, la description de vos mesures de sécurité, et de plus en plus souvent la preuve d’une évaluation externe récente.

C’est le point de jonction entre conformité et sécurité applicative : ces demandes ne se traitent pas au moment de la signature, mais se préparent en amont, et se documentent une fois pour toutes.