Pour un éditeur SaaS, tout le RGPD découle d'une seule question : sur ce traitement précis, êtes-vous sous-traitant de votre client ou responsable de traitement pour votre propre compte ? La réponse n'est pas globale, elle est traitement par traitement — et elle change ce que vous avez le droit de faire avec les accès, les journaux et les données de vos clients. Un éditeur qui n'a pas tranché cette question ne peut pas concevoir correctement son authentification, parce qu'il ne sait pas à qui il doit rendre des comptes.
Cet article propose une lecture opérationnelle et ne constitue pas un avis juridique. La qualification de chaque traitement et la rédaction des clauses associées relèvent de votre délégué à la protection des données et de vos conseils.
La double casquette, traitement par traitement
| Traitement | Rôle habituel de l'éditeur | Ce que cela impose côté accès |
|---|---|---|
| Données métier saisies par le client dans l'application | Sous-traitant | Aucun accès en dehors des instructions du client, et une trace de chaque accès effectué |
| Comptes des utilisateurs finaux du client | Sous-traitant | Le client reste maître des créations, suspensions et suppressions |
| Facturation, gestion du contrat, relation commerciale | Responsable de traitement | Vos propres durées de conservation et vos propres bases légales |
| Journaux techniques d'exploitation | Souvent les deux, selon la finalité | Séparer ce qui sert à exploiter le service de ce qui sert à investiguer pour le compte du client |
| Statistiques d'usage produit | À qualifier au cas par cas | Distinguer données agrégées et données rattachables à un utilisateur |
La ligne la plus piégeuse est la dernière. Beaucoup d'éditeurs analysent l'usage de leur produit en partant du principe que ce sont « leurs » données, alors que les événements portent sur des personnes dont le client est responsable. Cette qualification se pose avant de construire le tableau de bord, pas après.
Le support qui prend l'identité du client
La fonction permettant à un agent de support de se placer dans le contexte d'un utilisateur client est la plus utile du produit et la plus délicate juridiquement. Elle n'est pas interdite ; elle doit être encadrée.
Quatre conditions rendent la fonctionnalité défendable :
- une finalité explicite, décrite dans la documentation contractuelle et non découverte par le client au détour d'un incident ;
- un déclenchement tracé et nominatif : quel agent, à quelle heure, sur quel compte, pour quel ticket ;
- une restriction technique : durée limitée, périmètre limité, actions sensibles interdites ou soumises à une validation distincte ;
- une visibilité côté client, qui doit pouvoir consulter ces accès sans les demander.
L'authentification joue ici un rôle direct : c'est elle qui permet d'affirmer que l'agent qui a déclenché l'accès est bien celui qui figure au journal. Une méthode rejouable ou partagée ruine la valeur probante de toute la chaîne, ce qui rejoint la logique de l'authentification transactionnelle : c'est l'action qui doit être prouvée, pas seulement la session.
La préproduction, angle mort récurrent
Copier une base de production dans un environnement de test reste une pratique répandue, souvent avec des accès plus larges, une authentification allégée et une durée de vie indéterminée. Du point de vue du règlement, ces données restent des données personnelles traitées pour une finalité qui n'a généralement pas été prévue.
Deux mesures produisent un effet immédiat : appliquer aux environnements hors production le même niveau d'exigence d'accès qu'à la production tant qu'ils contiennent des données réelles, et rendre l'anonymisation ou la réduction des jeux de données plus simple que la copie brute — sinon la copie brute gagnera toujours.
Sous-traitance en cascade et localisation
Un éditeur SaaS s'appuie sur d'autres services : hébergement, envoi de messages, supervision, assistance externalisée, et souvent un fournisseur d'authentification. Chacun est un sous-traitant ultérieur, et le client final reste en droit de savoir qui compose la chaîne.
Trois vérifications structurent le sujet :
- Que détient chaque maillon ? Un fournisseur d'authentification qui conserve des identifiants, des numéros de téléphone ou des gabarits biométriques n'a pas le même profil qu'une architecture décentralisée qui ne détient aucune donnée identifiante et traite la biométrie localement sur l'appareil — c'est le parti pris de HIAsecure.
- Où sont les données, et sous quel droit ? La localisation de l'hébergement et la juridiction applicable au fournisseur conditionnent l'analyse des transferts hors Union européenne, sujet traité plus largement dans la dépendance technologique extra-européenne.
- Que se passe-t-il en cas d'incident chez un sous-traitant ultérieur ? Votre capacité à assister votre client dépend de ce que ce maillon peut vous fournir, et à quelle vitesse.
Le devoir d'assistance, qui se prépare en amont
Un client sous-traitant vous demandera deux choses, souvent dans l'urgence : l'aider à répondre à une demande d'exercice de droits, et l'aider à qualifier une violation. Les deux supposent des capacités techniques décidées longtemps avant.
Côté droits, il faut pouvoir extraire ou supprimer les données d'une personne sans exposer celles des autres locataires. Côté violation, il faut des journaux d'accès segmentés par client, exploitables, et conservés assez longtemps pour couvrir un délai de découverte réaliste — sans devenir eux-mêmes un entrepôt de données personnelles sans durée définie.
Séquence pour un éditeur
- Qualifiez chaque traitement dans un tableau court, et faites-le valider. Tout le reste en découle.
- Documentez la fonction de support avec identité, périmètre, durée et visibilité client.
- Traitez la préproduction : inventaire des copies, décision sur chacune.
- Publiez la liste de vos sous-traitants ultérieurs et tenez-la à jour ; c'est attendu et cela évite des échanges longs à chaque renouvellement.
- Testez une demande d'exercice de droits de bout en bout sur un client fictif.
- Vérifiez que vos journaux d'accès sont segmentés par locataire et exploitables sans traitement manuel.
FAQ
Sommes-nous responsables si notre client configure mal les droits de ses utilisateurs ?
La responsabilité se répartit selon les rôles : le client décide des accès de ses utilisateurs, vous fournissez les moyens de les gérer et de les tracer. Un produit qui ne permet pas de restreindre finement les droits reporte de fait le risque sur le client, ce qui devient un sujet contractuel autant que technique.
Le SSO du client suffit-il à couvrir nos obligations ?
Il couvre l'accès des utilisateurs finaux, pas les vôtres. Vos comptes d'administration, vos accès de support et vos comptes de service restent sous votre responsabilité, et ce sont eux qui donnent accès à l'ensemble des locataires.
Peut-on conserver les journaux d'authentification aussi longtemps qu'on veut ?
Non : ce sont des données personnelles, soumises à une durée de conservation justifiée par une finalité. La bonne démarche consiste à partir de l'usage réel — investigation, preuve en cas de contestation — puis à en déduire la durée, en la documentant.
Faut-il de l'authentification forte sur les comptes de service et les clés d'API ?
Ces identités ne s'authentifient pas comme des humains, mais elles doivent être inventoriées, portées par des secrets non partagés, cantonnées à un périmètre étroit et renouvelées. Ce qui compte est de pouvoir dire à tout moment quelle clé existe, pour quel usage, et qui l'a créée.
Aller plus loin : l'authentification cognitive, page pilier · ce que le RGPD attend des accès · NIS2 et les éditeurs SaaS · le vol de session chez les éditeurs