Les solutions SaaS occupent une place croissante pour tous les services qui nous entourent. En confiant à un prestataire l’hébergement et l’exploitation d’un outil, nous gagnons en simplicité apparente. Mais nous abandonnons souvent au passage une bonne partie de la maîtrise technique de nos traitements.

Cette dépendance pose une question simple au regard du RGPD : comment un responsable de traitement peut-il garantir le respect de ses obligations quand il ne maîtrise ni l’infrastructure, ni les mécanismes de sécurité, ni parfois l’ensemble des traitements réalisés sur les données de ses utilisateurs ?

L’examen de l’affaire Boulanger par la formation restreinte de la CNIL), le 22 octobre 2026, illustre en pratique ces difficultés.

Un responsable de traitement juridiquement responsable, mais techniquement dépendant

Le RGPD distingue le responsable de traitement, qui détermine les finalités et les moyens du traitement, du sous-traitant, qui traite les données pour le compte et sous les seuls ordres du responsable de traitement.

C’est le responsable de traitement qui reste garant de la conformité globale et doit pouvoir la démontrer. Il doit ainsi choisir exclusivement des sous-traitants présentant des garanties suffisantes et encadrer leurs activités, en application de l’article 28 du RGPD.

La répartition juridique se heurte pourtant à une réalité contractuelle et technique.

Dans beaucoup d’offres SaaS, le prestataire impose en réalité une plateforme standardisée dont il garde la totale maîtrise opérationnelle. Les possibilités de configuration sont limitées, correspondant exclusivement à des fonctionnalités proposées au catalogue du produit.

Les fonctionnalités elle-mêmes évoluent à la seule initiative du sous-traitant, qui reste maître de son offre produit, et n’apparaissent au catalogue que si le sous-traitant y trouve lui-même son compte.

Toute demande particulière passe par de longues négociations contractuelles, souvent vouées à l’échec sauf à être un client d’une taille conséquente.

Le client peut donc se retrouver responsable d’un traitement dont il ne maîtrise pas les moyens techniques essentiels voire les finalités elles-même. Or, le RGPD indique clairement que le responsable de traitement est celui qui détermine les finalités et les moyens du traitement. Dans un tel cas, qui est le réel responsable de traitement ?

Il est ainsi très probable que l’usage du SaaS mette en œuvre une co-responsabilité de traitement, alors qu’en pratique le prestataire rejette toute responsabilité en la matière, y compris par l’introduction de clauses de déresponsabilisation. Boulanger a mentionné ce problème lors de l’audience.

Des traitements que le client ne connaît pas toujours

Une plateforme SaaS peut proposer plusieurs fonctionnalités reposant sur une infrastructure commune : gestion des commandes, CRM, statistiques, marketing, assistance. Des données transmises au départ pour une fonctionnalité peuvent être conservées ou utilisées dans le cadre d’autres fonctionnalités auxquelles le responsable de traitement n’a pas souscrit.

Des traitements existent aussi généralement pour l’intérêt propre du prestataire : journaux d’exploitation, mesures d’audience, métriques d’utilisation des fonctionnalités, tests A/B de nouvelles fonctionnalités…

Dans le dossier Boulanger, le rapporteur a relevé que le sous-traitant conservait des données au-delà de la durée prévue, notamment pour des fonctionnalités CRM auxquelles Boulanger n’avait pas souscrit. Selon les éléments présentés à l’audience, la plateforme hébergeait environ 20 millions de comptes, alors que Boulanger s’attendait à quelque 300 000 entrées.

Une telle situation soulève plusieurs questions :

• Le responsable de traitement connaît-il l’ensemble des opérations effectuées sur ses données ?
• Peut-il vérifier les fonctionnalités réellement activées et les traitements associés ?
• A-t-il une visibilité suffisante sur les durées de conservation effectives et la sécurité les encadrant ?
• Peut-il s’assurer que les données ne sont pas réutilisées pour des finalités qu’il n’aurait pas déterminées ?

La minimisation des données et la limitation de leur conservation, prévues à l’article 5 du RGPD, ne peuvent pas être respectées sur la seule base des options cochées dans une interface ou des engagements écrits dans un contrat. Il faut que les pratiques effectives correspondent à ces engagements.

Recourir à une plateforme mutualisée ne dispense donc pas le responsable de traitement de vérifier ce qu’elle fait réellement et d’en connaître tous les détails, même ceux dont il n’a pas un usage direct.

Des obligations difficiles à satisfaire sans maîtrise technique

L’article 32 du RGPD impose au responsable de traitement et au sous-traitant de mettre en œuvre des mesures techniques et organisationnelles appropriées au risque.

Cela suppose de pouvoir apprécier les mécanismes de sécurité réellement déployés : authentification, gestion des habilitations, journalisation, cloisonnement, détection des accès anormaux, réponse aux incidents.

Or un client SaaS n’a pas nécessairement les droits d’accès, les moyens techniques, ou les informations qui lui permettraient de vérifier ces éléments.

Dans le dossier Boulanger, le rapporteur a relevé des comptes partagés protégés par des mots de passe de quatre caractères, l’absence de journalisation des accès, et l’absence de cloisonnement entre les différentes plateformes géographiques. L’attaquant aurait ainsi pu émettre plus de 280 000 requêtes pour exfiltrer des données sans être détecté.

Boulanger a fait valoir qu’il ne pouvait pas imposer à son prestataire des moyens d’authentification plus robustes, et que ses contrôles s’étaient essentiellement limités à des documents contractuels et à des échanges avec son sous-traitant. La situation s’était uniquement débloquée une fois la violation de données constatée, les deux entreprises se retrouvant alors au pied du mur avec un risque de contrôle et de sanction de la part de la CNIL.

Boulanger a d’ailleurs précisé que les traitements mis en œuvre lui étaient inconnus et que son sous-traitant les lui avait cachés, malgré des audits papier et des échanges oraux.

Cette défense met en lumière une difficulté structurelle inhérente au mode SaaS : un audit documentaire ne permet pas de vérifier la sécurité réelle d’un système d’information.

Un contrat peut prévoir une authentification robuste, une journalisation complète, et une conservation limitée. Encore faut-il vérifier que ces mesures existent, qu’elles fonctionnent, et qu’elles couvrent l’ensemble des traitements concernés. Une offre peut avoir convenue que certains traitements ne seront pas réalisés. Encore faut-il pouvoir s’assurer qu’ils sont réellement désactivés.

Le responsable de traitement ne peut pas présumer que son prestataire respecte ses engagements. L’affaire Boulanger en illustre un angle mort dans une approche « zéro-trust » : la confiance en ses sous-traitants ne doit pas non plus être acquise et les responsables de traitement doivent intégrer ce fait dans leurs analyses de risques.

Des audits qui se heurtent aux limites du modèle SaaS

L’article 28(3)h du RGPD prévoit que le sous-traitant met à la disposition du responsable de traitement les informations nécessaires pour démontrer le respect de ses obligations et permettre la réalisation d’audits, y compris des inspections.

En pratique, exercer ce droit est difficile dans le contexte d’une offre SaaS.

Les prestataires privilégient souvent des rapports standardisés, des certifications, ou des questionnaires de conformité. Ces éléments sont utiles, mais ils ne répondent pas à toutes les questions propres à un traitement donné. Ils immunisent encore moins contre des traitements cachés réalisés à l’insu du responsable de traitement.

Un certificat ne démontre pas que les données d’un client sont correctement cloisonnées. Un questionnaire ne prouve pas qu’un mécanisme de journalisation fonctionne. Un audit papier de la plateforme ne garantit pas que les options choisies par le client sont correctement paramétrées.

L’ANSSI préconise des audits de sécurité réguliers. La CNIL a également sanctionné l’absence de contrôle effectif des prestataires, dans sa délibération SAN-2022-021 du 24 novembre 2022 concernant EDF, où elle notait déjà des absences d’audit sérieux, fondés exclusivement sur des questionnaires papiers et sans vérification sur site. Il en aura été de même durant l’audience concernant Boulanger, durant laquelle le Rapporteur rappelait la nécessité d’un audit complet au moins une fois par an.

La conformité ne peut donc reposer sur la seule confiance accordée au prestataire, ni sur des engagements contractuels. Elle exige des contrôles effectifs, permettant de vérifier les pratiques réellement mises en œuvre.

Cependant de tels audits sont difficiles à organiser lorsque l’infrastructure de la solution SaaS est mutualisée entre de nombreux clients, repose sur plusieurs sous-traitants, ou constitue un élément central du savoir-faire du prestataire.

En pratique, les offres SaaS ne permettent aucunement ce type d’audit. Les modèles commerciaux au rabais, voire financés par la publicité, n’incitent de plus pas à offrir ce type de prestation complexes et coûteuses. Difficile pour 20 € / mois d’envisager de bloquer toute une DSI pendant plusieurs jours chaque année avec des accès privilégiés à l’infrastructure.

Un rapport de force contractuel défavorable aux clients

Un client isolé pèse peu face à un grand fournisseur SaaS, y compris apparemment quand on s’appelle Boulanger. Il est souvent impossible d’obtenir la modification d’un paramètre technique, un droit d’audit approfondi, ou une garantie contractuelle particulière sans accepter des coûts supplémentaires ou des délais importants. Un refus constant est très courant, le prestataire n’ayant aucun intérêt à de telles modifications.

Dans le dossier Boulanger, l’entreprise a ainsi expliqué à la CNIL que l’obtention d’un délai de conservation de 90 jours avait nécessité plus d’un an de négociations. Son sous-traitant n’avait finalement pas déployé cette fonctionnalité suite à la demande de Boulanger, mais plutôt lorsqu’elle était devenue intéressante pour son offre commerciale. Elle avait été alors déployée sur l’ensemble du parc, et unilatéralement imposée à Boulanger à cette occasion.

Boulanger a aussi dénoncé des clauses limitatives de responsabilité et la difficulté à contrôler des traitements réalisés à son insu. La liberté contractuelle ne garantit ainsi pas un équilibre réel entre les parties.

Mais expliquer n’est pas excuser.

Le responsable de traitement reste juridiquement tenu de sélectionner un prestataire présentant des garanties suffisantes. Il en endosse l’entière et seule responsabilité. Si les garanties indispensables ne sont pas négociables, il doit alors envisager une autre solution, y compris se passer de SaaS.

La dépendance technique se transforme ainsi en dépendance juridique : le client reste responsable de la conformité, sans disposer des leviers nécessaires pour l’assurer pleinement, restant à la merci de son prestataire.

Le client reste le responsable de son sous-traitant

Le RGPD prévoit, à son article 28, que le responsable doit choisir exclusivement un prestataire offrant des garanties suffisantes, et qu’il doit être le seul à définir les finalités et les modalités de traitement. Le sous-traitant doit exclusivement agir dans le cadre des instructions reçues, avec une autonomie limitée à des choix techniques simples.

L’affaire Boulanger est un bel exemple des conséquences d’une telle responsabilité juridique. Faute d’encadrement de cette sous-traitance, Boulanger en endosse la totale responsabilité.

Boulanger disposera toujours des outils juridiques légaux pour poursuivre elle-même son prestataire en responsabilité, mais c’est bien finalement elle qui devra régler l’éventuelle amende de la CNIL et subir le préjudice sur sa réputation.

Le RGPD dans le modèle SaaS

Le modèle SaaS n’est pas incompatible en soit avec le RGPD. Il peut même favoriser la sécurité lorsqu’un prestataire spécialisé dispose de moyens supérieurs à ceux de ses clients.

Mais cette mutualisation ne fonctionne que si elle s’accompagne d’une transparence suffisante, de garanties vérifiables, et d’une capacité effective à faire respecter les obligations légales.

Le dossier Boulanger illustre le risque d’un décalage entre la responsabilité juridique du client et sa maîtrise réelle de la plateforme. Il interroge aussi la capacité des responsables de traitement à vérifier des traitements dont ils ignorent parfois l’existence, et l’effectivité des droits d’audit prévus par le RGPD.

Pour PURR, la conformité des solutions SaaS ne peut se résumer à des contrats, des certifications, ou des déclarations de sécurité. Elle doit pouvoir être démontrée dans les faits, et fait en pratique bien souvent totalement défaut.

Cela suppose des prestataires qui acceptent des contrôles effectifs, des contrats qui garantissent des moyens d’action suffisants, et des responsables de traitement qui évaluent réellement et régulièrement les risques liés à leurs dépendances techniques.

Problème : aucune solution ne propose aujourd’hui un tel niveau de contrôle. Toutes sont donc en pratique incompatibles avec le RGPD.

Le SaaS mutualisé atteint ses limites : faut-il revenir à l’hébergement dédié ?

Le modèle classique du SaaS repose sur une plateforme unique, mutualisée entre de nombreux clients. Cette architecture réduit les coûts et simplifie l’exploitation, mais elle présente des limites structurelles lorsque le prestataire garde seul la maîtrise des configurations, des fonctionnalités, et des traitements réalisés sur les données.

La mutualisation favorise les effets de bord : une fonctionnalité activée pour certains clients peut affecter les données d’autres clients, les paramètres de conservation peuvent être communs à plusieurs organisations, et le cloisonnement effectif des données devient une exigence critique. Ceci alors que les contraintes techniques de ce type de mesure technique s’opposent à celles du produit. Le dossier Boulanger montre les conséquences possibles de cette perte de maîtrise.

Difficile en effet d’envisager le déploiement de bases de données dédiées à chaque client et physiquement séparées les unes des autres quand le modèle commercial à bas coût impose la minimisation de la maintenance et donc une mutualisation tant des serveurs que des bases de données.

Une autre architecture consisterait à fournir à chaque client une instance propre, « virtualisée », dont les données, les configurations, et les mécanismes de sécurité seraient isolés de ceux des autres clients. Cette approche facilite le cloisonnement, la personnalisation des paramètres de conservation, et le contrôle des accès.

Mais encore une fois, un tel modèle SaaS « virtualisé » n’existe pas ou peu en pratique.

Les exigences du RGPD peuvent donc inciter les organisations à privilégier des solutions hébergées sur une infrastructure dédiée, des appliances déployées dans leur propre système d’information, voire un hébergement sur site. Ces modèles permettent potentiellement de retrouver une maîtrise plus directe des données et des opérations techniques.

Le paradoxe est que le RGPD, sans imposer aucun modèle d’hébergement particulier, peut rendre le SaaS mutualisé difficile à retenir lorsque le responsable de traitement ne dispose pas des moyens nécessaires pour contrôler effectivement le traitement.

Lorsque le prestataire refuse les garanties indispensables, le choix ne devrait pas se limiter à accepter une conformité invérifiable : il reste toujours possible de recourir à une architecture offrant une maîtrise réelle des données et des moyens de sécurité.

Et si finalement, le seul modèle compatible avec le RGPD était l’auto-hébergement ?

C’est en tout cas la conclusion qu’en a tirée notre Association, qui s’auto-héberge presque à 100 %. Les offres SaaS actuelles n’offrent aucune garantie suffisantes.

La seule obtention d’un Data Privacy Agreement, pourtant obligatoire, réclame déjà des efforts sur-humains. Les documents produits ne correspondent pas aux obligations légales, et négocier une version correcte est impossible.

Les traitements propres au fournisseur, comme ses métriques d’usages, pourtant soumis au strict consentement de l’utilisateur final, ne sont pas débrayables ou non documentées, ou fondés sur un intérêt légitime illicite, sans possibilité d’opposition.

Il est en pratique impossible de savoir ce qui serait fait des données si nous les leurs confions. Donc, nous nous passons de ces services.

Les seules parties non opérées en propre sont des outils peu critiques comme Framatalk pour nos réunions mensuelles, et qui seraient complexes à maintenir nous-même. Ces traitement ont peu de possibilités de dérapages, y compris avec un sous-traitant malveillant. Sous-traitant dont nous avons dans tous les cas une relative bonne confiance en la gestion (Framasoft 🥰).

Ou encore la partie bancaire, qui malheureusement ne connaît pas d’alternatives réellement propre…