En outre, on considère généralement que la définition des finalités du traitement l'emporte sur celle des moyens lorsqu'il s'agit d'établir la responsabilité d'une organisation.
Oui, mais justement. Définir les finalités implique être responsable de traitement. Ça c’est clair net et précis.
Mais l’inverse n’est pas vrai : ne pas définir les finalités n’impliquent pas de ne pas être responsable, il reste encore au moins à étudier la définition des moyens. D’autant plus que l’un des 2 soit responsable de traitement n’empêche pas l’autre de pouvoir l’être (co-responsable de traitement). Et que, y compris pour une même donnée, le statut de processeur de données n’est pas exclusif d’être aussi responsable de traitement.
Le 1er diagramme de la page 46 évacue rapidement les cas où tu es responsable de traitement de manière évidente (tu as dis ou écris que tu l’étais ou une loi t’y contraint).
On arrive sur « tu fais quoi en pratique ». Les 2 portes de sortie « data processor » implique « decision based on general security objective set by the other party » et « solely in accordance with its instruction ».
Dans le cas du SaaS, c’est pas évident parce que le logiciel existait déjà avant la conclusion du contrat, donc les décisions ayant été prises sans lui, le cas « 2- solely » est difficile à défendre. Et pour le cas « 1- set by the other party », le mécanisme de décision est au mieux inversé. On part de finalité et de moyens déjà offerts par un logiciel existant et on s’arrange pour faire matcher les objectifs du client avec les possibilités (« oh vous conservez 6 mois chez vous ? On aurait plutôt dit 3, mais aller, on va marquer 6, ça nous va aussi mais on est bien d’accord qu’on n’écrit ça nul part hein » ou autre « ah zut, vous fait machin-truc pour votre maintenance ? Bon, on va l’indiquer aussi chez nous et on en prend la DC et on vous dit DP »).
L’arrangement est au final un jeu de dupe, on change le registre de traitement du client avec les possibilités du logiciel SaaS plutôt que d’arranger le logiciel SaaS pour coller avec le registre de traitement.
Sur un contrôle APD, ça ferait quand même vachement mauvaise foi d’avoir trouver un presta 100% conforme à tes exigences alors qu’il existait depuis 10 ans et n’a pas fait de développement spécifique notable pour toi.
Surtout que l’objectif de ce jeu de dupe est clair : éviter la responsabilité de traitement du prestataire (qu’il préférerait ne pas assumer ou te le fera payer, cf Microsoft & IAB), éviter de devoir aller voir ailleurs, et en plus risquer de devoir constater qu’il n’existe pas d’offre SaaS correspondant strictement aux besoins et donc de devoir investir dans un développement de produit ad-hoc ou on-premise (cher, long, etc).
En pratique sur un produit SaaS, on devrait donc plutôt sortir sur 4.1 « you are the controller ». Ce qui ne serait pas/moins vrai pour un logiciel à façon du coup, développé spécifiquement pour tes besoins propres (quitte à partir d’une base SaaS existante), ou on-premise où tu gères assez finement ton paramétrage et tes accès, et où tu sortirais en 4.2/4.3.
Sur toutes les finalités offertes par un logiciel SaaS, la proba d’avoir du 100% « data processor » est quand même faible... En pratique, on va avoir :
- « client DC, presta DP » sur peu de finalité : celles spécifiquement créées par le client à partir du logiciel en SaaS et dont le presta se fout un peu (« gérer le service client via un chatbot », « réserver un billet de train via un chatbot »...)
- « client/presta co-DC » sur un petit bout : toutes les finalités existantes dans le produit avant l’arrivée du nouveau client et correspondant à 100% à un besoin précis de ce client avant le choix du prestataire (« conserver un historique des échanges », « répondre à une demande d’accès RGPD »).
- « presta DC » pour le reste : toutes celles existantes dans le produit avant l’arrivée du nouveau client et ne correspondant pas à un besoin précis à 100% du client avant le choix du prestataire (« maintenir la plateforme », « offrir du support à mes clients », « obtenir des stats/KPI de ma plateforme »). Pour moi ça risque d’être ça le très gros du paquet.
J’ai même des cas assez chiants à faire rentrer dans les cases...
Quid d’une analyse côté client qui montre un besoin de rétention d’historique à 3 mois côté client quand la seule possibilité côté SaaS est de le faire à 6 mois ? Tu vas quand même chez ton prestataire en violant ton propre registre de traitement ? 🤔
Ton analyse dit 6 mois mais le SaaS fait 3 mois. Tu revois ton analyse à 3 mois en reconnaissant avoir mal fait ton boulot de minimisation dans l’analyse préliminaire vu qu’a priori c’était nécessaire de conserver 6 mois minimum ? 🤔
En théorie tu es supposé aller voir ailleurs dans les 2 cas du coup... 🤷
Et si tu trouves un presta SaaS capable d’adapter son soft existant et ses paramétrages à tes propres besoins de conformité sans toucher à ceux de ses autres clients (par exemple garantir cette suppression à 3 mois pour un client et à 6 mois pour les autres, ou désactiver toute télémétrie et acte de maintenance pour l’un mais pas pour l’autre, ou virer de stats de KPI tout ce qui est généré par les usages d’un client donné), je doute que le tarif soit si intéressant que ça par rapport à un développement à façon... On serait rapidement plus proche en pratique au moins du on-premise, ou à des usines à gaz type SAP... 🤔
[^] # Re: Jurisprudence pour l’obligation d’auto-hébergement ?
Posté par Aeris (site web personnel) . En réponse au journal Une surprenante décision de la justice belge. Évalué à 2. Dernière modification le 07 février 2022 à 15:58.
Oui, mais justement. Définir les finalités implique être responsable de traitement. Ça c’est clair net et précis.
Mais l’inverse n’est pas vrai : ne pas définir les finalités n’impliquent pas de ne pas être responsable, il reste encore au moins à étudier la définition des moyens. D’autant plus que l’un des 2 soit responsable de traitement n’empêche pas l’autre de pouvoir l’être (co-responsable de traitement). Et que, y compris pour une même donnée, le statut de processeur de données n’est pas exclusif d’être aussi responsable de traitement.
C’est aussi plutôt visible dans les lignes directrices EDPB.
Le 1er diagramme de la page 46 évacue rapidement les cas où tu es responsable de traitement de manière évidente (tu as dis ou écris que tu l’étais ou une loi t’y contraint).
On arrive sur « tu fais quoi en pratique ». Les 2 portes de sortie « data processor » implique « decision based on general security objective set by the other party » et « solely in accordance with its instruction ».
Dans le cas du SaaS, c’est pas évident parce que le logiciel existait déjà avant la conclusion du contrat, donc les décisions ayant été prises sans lui, le cas « 2- solely » est difficile à défendre. Et pour le cas « 1- set by the other party », le mécanisme de décision est au mieux inversé. On part de finalité et de moyens déjà offerts par un logiciel existant et on s’arrange pour faire matcher les objectifs du client avec les possibilités (« oh vous conservez 6 mois chez vous ? On aurait plutôt dit 3, mais aller, on va marquer 6, ça nous va aussi mais on est bien d’accord qu’on n’écrit ça nul part hein » ou autre « ah zut, vous fait machin-truc pour votre maintenance ? Bon, on va l’indiquer aussi chez nous et on en prend la DC et on vous dit DP »).
L’arrangement est au final un jeu de dupe, on change le registre de traitement du client avec les possibilités du logiciel SaaS plutôt que d’arranger le logiciel SaaS pour coller avec le registre de traitement.
Sur un contrôle APD, ça ferait quand même vachement mauvaise foi d’avoir trouver un presta 100% conforme à tes exigences alors qu’il existait depuis 10 ans et n’a pas fait de développement spécifique notable pour toi.
Surtout que l’objectif de ce jeu de dupe est clair : éviter la responsabilité de traitement du prestataire (qu’il préférerait ne pas assumer ou te le fera payer, cf Microsoft & IAB), éviter de devoir aller voir ailleurs, et en plus risquer de devoir constater qu’il n’existe pas d’offre SaaS correspondant strictement aux besoins et donc de devoir investir dans un développement de produit ad-hoc ou on-premise (cher, long, etc).
En pratique sur un produit SaaS, on devrait donc plutôt sortir sur 4.1 « you are the controller ». Ce qui ne serait pas/moins vrai pour un logiciel à façon du coup, développé spécifiquement pour tes besoins propres (quitte à partir d’une base SaaS existante), ou on-premise où tu gères assez finement ton paramétrage et tes accès, et où tu sortirais en 4.2/4.3.
Sur toutes les finalités offertes par un logiciel SaaS, la proba d’avoir du 100% « data processor » est quand même faible... En pratique, on va avoir :
- « client DC, presta DP » sur peu de finalité : celles spécifiquement créées par le client à partir du logiciel en SaaS et dont le presta se fout un peu (« gérer le service client via un chatbot », « réserver un billet de train via un chatbot »...)
- « client/presta co-DC » sur un petit bout : toutes les finalités existantes dans le produit avant l’arrivée du nouveau client et correspondant à 100% à un besoin précis de ce client avant le choix du prestataire (« conserver un historique des échanges », « répondre à une demande d’accès RGPD »).
- « presta DC » pour le reste : toutes celles existantes dans le produit avant l’arrivée du nouveau client et ne correspondant pas à un besoin précis à 100% du client avant le choix du prestataire (« maintenir la plateforme », « offrir du support à mes clients », « obtenir des stats/KPI de ma plateforme »). Pour moi ça risque d’être ça le très gros du paquet.
J’ai même des cas assez chiants à faire rentrer dans les cases...
Quid d’une analyse côté client qui montre un besoin de rétention d’historique à 3 mois côté client quand la seule possibilité côté SaaS est de le faire à 6 mois ? Tu vas quand même chez ton prestataire en violant ton propre registre de traitement ? 🤔
Ton analyse dit 6 mois mais le SaaS fait 3 mois. Tu revois ton analyse à 3 mois en reconnaissant avoir mal fait ton boulot de minimisation dans l’analyse préliminaire vu qu’a priori c’était nécessaire de conserver 6 mois minimum ? 🤔
En théorie tu es supposé aller voir ailleurs dans les 2 cas du coup... 🤷
Et si tu trouves un presta SaaS capable d’adapter son soft existant et ses paramétrages à tes propres besoins de conformité sans toucher à ceux de ses autres clients (par exemple garantir cette suppression à 3 mois pour un client et à 6 mois pour les autres, ou désactiver toute télémétrie et acte de maintenance pour l’un mais pas pour l’autre, ou virer de stats de KPI tout ce qui est généré par les usages d’un client donné), je doute que le tarif soit si intéressant que ça par rapport à un développement à façon... On serait rapidement plus proche en pratique au moins du on-premise, ou à des usines à gaz type SAP... 🤔