Exemples de normes

Nous nous proposons maintenant d’expliciter, en fonction des formalismes que nous avons introduits, la traduction en logique DLP de quelques normes fictives traitant de la protection des donn´ees personnelles. Nous nous placerons dans le cas d’un agent PAw (repr´esent´e par self) appartenant `a un employ´e de la soci´et´e ✭✭ groupe W ✮✮ travaillant en Syldavie. Nous utiliserons les autorit´es normatives fictives suivantes :

– la l´egislation syldave : syldavianLaw ;

– le r´eglement de la soci´et´e ✭✭ groupe W ✮✮ : wGroupReg ;

– le directeur du groupe pour la branche ✭✭ Syldavie ✮✮ : wSylChair – le contrat entre M. Pignon et le groupe W : wPignonContract ; – les pr´ef´erences de l’utilisateur : user.

Nous proposons une norme fictive pour chacun des six axes r´eglementaires et discutons de sa traduction en logique DLP. Pour chaque norme, nous donnerons une ou plusieurs formules DLP. La traduction effective de la norme sera la conjonction de ces formules.

Les normes ´etant `a l’origine exprim´ees en fran¸cais, elles sont sujettes `a interpr´etation avant d’ˆetre traduites en logique DLP. Cette n´ecessaire interpr´etation est sujette `a discussion, et nous ne nous pr´etendons pas comp´etents pour expliciter tout ´el´ement de r`eglementation d’une mani`ere inattaquable. Nous souhaitons seulement mettre en lumi`ere la n´ecessit´e d’une intervention hu-maine lorsque les normes pr´eexistantes n’ont pas ´et´e formul´ees de mani`ere `a ˆetre ais´ement traduites dans un langage formel. Cette ´etape d’interpr´etation peut ˆetre ´evacu´ee lorsque les normes ne proviennent pas d’un texte en langue naturelle mais d’un ´editeur de pr´ef´erences, ce dernier permettant de contraindre la forme des phrases et autorisant un traitement purement automatique.

4.3.3.1 Robustesse des formules au dynamisme du contexte normatif Comme nous l’avons d´ej`a vu, le contexte normatif dans lequel ´evolue l’agent PAw est dy-namique. De nouvelles normes ou autorit´es normatives sont susceptibles d’apparaˆıtre, d’autres peuvent disparaˆıtre. `A chacune de ces modifications du contexte normatif (qui sont cependant suppos´ee survenir assez rarement dans le cas o`u l’agent PAw ne se place pas de lui-mˆeme dans un nouveau contexte), la base de normes de l’agent correspondant `a ce contexte sera r´einitialis´ee, et

l’ensemble des formules d´eriv´ees sera recalcul´e. En cons´equence, les formules DLP repr´esentant les normes doivent prendre en compte le fait que leur existence dans le syst`eme logique peut ˆetre post´erieure `a certains faits sur lesquels elles portent. Si l’on prend l’exemple d’une norme d’obligation qui a pour condition d’application le fait qu’un traitement ait ´et´e op´er´e par l’agent dans le pass´e, la traduction de cette norme doit permettre de d´eriver l’obligation correspondante mˆeme si la base de norme a ´et´e r´einitialis´ee entre le moment auquel le traitement a eu lieu et l’instant pr´esent (quitte `a rendre partiellement redondante la traduction de la norme24). Nous verrons dans les exemples comment prendre cela en compte.

Le dynamisme du contexte normatif entraˆıne donc une certaine volatilit´e de la base de normes. En cons´equence, la caract´erisation des violations effectu´ees par un agent `a des dates d´etermin´ees du flot temporel est ´egalement volatile. Afin de permettre `a l’agent PAw de raisonner tout de mˆeme sur ses violations pass´ees (mˆeme si les normes qui les ont engendr´ees ne sont plus en vigueur), nous supposons l’existence d’un proc´ed´e de stigmatisation des violations : lorsqu’une violation est d´eriv´ee, elle est extraite du syst`eme logique DLP pour ˆetre introduite dans la base de croyances de l’agent avec toutes les informations n´ecessaires s’y rattachant25.

L’agent PAw peut ainsi raisonner efficacement dans un contexte normatif dynamique tout en restant conscient de ses violations pass´ees.

4.3.3.2 Exemple sur l’axe ✭✭ Information ✮✮

Extrait du r`eglement int´erieur du groupe W : ✭✭ Les clients doivent ˆetre inform´es au moins une semaine `a l’avance de la nature de tout traitement utilisant leurs donn´ees personnelles. ✮✮

Cette norme est formul´ee de mani`ere simple, sous une forme qui peut apparaˆıtre couramment dans des r`eglements ou des contrats. Elle pr´esente n´eanmoins des difficult´es d’interpr´etation non triviales pour un agent artificiel. Cette obligation concerne en effet directement les capacit´es de planification de l’agent : il doit la consid´erer seulement s’il a pr´evu de mettre en œuvre un traitement utilisant des donn´ees personnelles.

La norme vue comme une interdiction

Une premi`ere interpr´etation de cette norme consiste `a la voir comme une interdiction de proc´eder au traitement si la condition n’a pas ´et´e respect´ee. Trois cas sont alors `a consid´erer, suivant les actions d´ej`a men´ees par l’agent :

1. Le client n’a pas encore ´et´e inform´e : la norme exprime alors une interdiction de proc´eder au traitement, interdiction dont on sait qu’elle peut ˆetre maintenue au moins une se-maine, ind´ependamment des actions futures de l’agent. Il paraˆıt donc naturel ici d’utiliser l’op´erateur d’interdiction maintenue. Si nous consid´erons qu’il faut ´egalement exprimer la relation entre le client et le traitement (via le pr´edicat d’´etat owner qui l’identifie comme propri´etaire d’une donn´ee utilis´ee dans un traitement particulier), nous repr´esenterons

24 Il est possible de s’affranchir de cette redondance en introduisant dans les conditions d’application des normes une formule temporelle d´etectant une ´eventuelle r´einitialisation de la base dans le pass´e (via l’introduction d’une nouvelle proposition d´edi´ee). Pour ne pas alourdir inutilement des notations d´ej`a complexes, nous nous accomoderons de cette redondance purement formelle.

25

Il faut toutefois noter que si le proc´ed´e de stigmatisation permet un raisonnement sur les violations pass´ees dans la couche cognitive (doxastive) de l’agent PAw, il ne permet pas toujours de fonder des normes sur ces violations. L’utilisation de normes contrary-to-duties, par exemple, est donc limit´e par le dynamisme du contexte normatif.

123 Utilisation de la logique DLP

donc cette situation de la mani`ere suivante en SDL : actionType(ProcessID, ActionType)

H¬informActionType(self, Client, ProcessID, ActionType) owner(ProcessID, DataID, Client) date(δ) ∧ X^7∗24δ           

→ F or^wGroupReg_self (perform(self, ProcessID), δ)

(4.80) 2. Le client a ´et´e inform´e il y a moins d’une semaine : la norme interdit alors que le traitement ait lieu avant un certain d´elai, d´ependant de la date `a laquelle le client a ´et´e inform´e. Si l’on consid`ere que l’agent a toujours ´et´e conscient de cette norme, alors on sait qu’`a cause du premier cas de figure, une obligation maintenue a ´et´e g´en´er´ee et qu’il existe une obligation imm´ediate de proc´eder au traitement (et ce jusqu’`a une semaine apr`es l’information du client). Cependant, si la norme est r´ecente (i.e. si la base de normes a ´et´e r´einitialis´ee il y a moins d’une semaine), aucune obligation maintenue n’a ´et´e g´en´er´ee. Il paraˆıt donc prudent ici de g´en´erer automatiquement une interdiction imm´ediate, mˆeme si potentiellement redondante avec la pr´ec´edente formule :

actionType(ProcessID, ActionType) P informActionType(self, Client,

ProcessID, ActionType)

X^−7∗24H⁻¬informActionType(self, Client, ProcessID, ActionType)

owner(ProcessID, DataID, Client)

              

→ F or_self^wGroupRegperform(self, ProcessID)

(4.81) 3. Le client a ´et´e inform´e il y a une semaine ou plus : la norme n’interdit plus la mise en œuvre du traitement. Il paraˆıtrait donc naturel dans ce cas de g´en´erer une permission imm´ediate de proc´eder au traitement. N´eanmoins, dans certains cas de figure cela pourrait amener `

a l’inconsistance du syst`eme. En effet, si le traitement en question utilise les donn´ees de deux clients et que seul le premier a ´et´e inform´e dans les temps, alors la norme engendrera `

a la fois une interdiction et une permission sur la mˆeme formule. Afin que l’agent puisse raisonner convenablement dans les cas plus complexes, nous nous contenterons donc de ne g´en´erer aucune notion d´eontique dans ce cas d’esp`ece, qui ne sera donc pas repr´esent´e par une formule DLP. Ainsi, dans le cas simple o`u un seul client, correctement inform´e, est concern´e, la permission (et mˆeme la gratuit´e) de l’action pourra ˆetre d´eriv´ee au besoin par une n´egation par l’´echec. Dans le cas complexe que nous avons ´evoqu´e, l’agent ne verra qu’une interdiction et aucune permission : le syst`eme logique restera coh´erent et lui interdira de proc´eder au traitement26.

La norme vue comme une obligation

La mani`ere compl´ementaire de consid´erer cette norme est de la voir d’un point de vue plus t´el´eologique : si l’agent a d´ej`a pour but de proc´eder au traitement dans un futur identifi´e, alors la norme lui dicte une obligation d’informer le client. Il peut donc ˆetre int´eressant de g´en´erer des formules d’obligation dans les cas o`u celles-ci font sens, et ce mˆeme si elles sont redondantes avec

26

Cette prise de position est tout-`a-fait coh´erente avec la vision philosophique que nous avons des modalit´es d´eontiques dans le cadre de l’agent PAw : elles servent `a contraindre son comportement. Ainsi, une permission (au sens du dual logique de l’obligation) ne lui donne pas un droit `a l’action, elle d´enote simplement l’absence d’interdiction.

les interdictions conditionnelles d´ej`a ´etablies. En effet, suivant les cas il peut ˆetre plus pratique pour l’agent de raisonner `a partir d’obligations ou d’interdictions. Encore une fois, plusieurs cas sont `a consid´erer :

1. Le client n’a pas ´et´e inform´e et le traitement est pr´evu `a une semaine ou plus dans le futur. Dans ce cas de figure, il faut signifier `a l’agent qu’il a l’obligation d’informer le client avant une certaine date limite δ (situ´ee une semaine avant le traitement). La formule suivante permet de caract´eriser cette date limite et de g´en´erer une obligation avec ´ech´eance27 :

actionType(ProcessID, ActionType) date(δ)

F (δ ∧ X^7∗24−1perform(self, ProcessID)) H¬informActionType(self, Client,

ProcessID, ActionType) owner(ProcessID, DataID, Client)

              

→ Ob^wGroupReg_self (informActionType(self, Client, ProcessID, ActionType), δ)

(4.82) 2. Le client n’a pas ´et´e inform´e et le traitement est pr´evu `a moins d’une semaine dans le futur. Dans ce cas de figure, aucune obligation ne permettra `a l’agent de respecter la norme. Le caract`ere contrevenant de cette intention est d´ej`a caract´eris´e par la premi`ere des interdictions que nous avons g´en´er´ees, nous n’ajoutons donc pas ici de nouvelle formule `

a la traduction de la norme.

3. Le client a ´et´e inform´e et le traitement est pr´evu une semaine ou plus apr`es la date de cette information. Ici, l’agent a d´ej`a tout fait pour se conformer aux prescriptions de la norme. Il n’y a pas d’obligation suppl´ementaire `a exprimer, seule une permission pourrait d´ecrire la situation et nous avons d´ej`a vu qu’il est pr´ef´erable de s’en abstenir. Nous n’ajoutons donc pas de nouvelles formule.

4. Le client a ´et´e inform´e et le traitement est pr´evu moins d’une semaine apr`es la date de cette information. Encore une fois, aucune obligation ne peut caract´eriser un comporte-ment de l’agent qui serait compatible avec la norme. Sa violation est caract´eris´ee soit par l’interdiction maintenue qui a ´et´e g´en´er´ee `a l’instant pr´ec´edent l’information du client, soit (dans le cas limite d’une r´einitialisation r´ecente de la base de normes) par l’interdiction imm´ediate qui surviendra au moment du traitement. Encore une fois, nous n’ajoutons donc pas de nouvelle formule `a la traduction.

4.3.3.3 Exemple sur l’axe ✭✭ Consentement ✮✮

Extrait du contrat entre M. Pignon et le groupe W : ✭✭ L’accord expr`es et pr´ealable de M. Pignon est n´ecessaire `a toute utilisation qui pourrait ˆetre faite de son num´ero de compte bancaire. ✮✮

Ici encore, la norme peut ˆetre consid´er´ee avec deux optiques diff´erentes : ou bien c’est une restriction sur la mise en œuvre du traitement, ou bien c’est une obligation inh´erente `a la planification du traitement. Dans le premier cas, on interdit les traitements auxquels M. Pignon

27

Le −1 peut sembler ´etrange dans l’exposant de l’op´erateur X. Il est dˆu au fait que dans l’op´erateur d’obligation avec ´ech´eance, δ est une limite stricte alors que la norme pr´ecise que l’intervalle de temps entre information et traitement doit ˆetre d’une semaine ✭✭ au moins ✮✮, ce qui sugg`ere une inclusion des bornes. Le lecteur pourra v´erifier par lui-mˆeme d’une part que ce −1 permet de satisfaire `a ces exigences, et d’autre part que les autres formules pr´ec´edemment propos´ees correspondent bien `a cette s´emantique temporelle pr´ecise de la norme exprim´ee.

125 Utilisation de la logique DLP

n’a pas d´ej`a consenti (traitements dans lesquels son num´ero de compte bancaire est impliqu´e, bien ´evidemment28) :

owner(ProcessID, Account, pignon) dataType(ProcessID, Account,

Ecom.Payment.Bank.PayerAccountNumber) H¬consent(pignon, self, ProcessID))

       → F or^{wPignonContract}_self perform(self, ProcessID) (4.83) Dans le second cas, on connaˆıt d´ej`a la date future `a laquelle le traitement est pr´evu. On peut donc g´en´erer une obligation avec ´ech´eance sur le consentement de M. Pignon. Il est int´eressant de noter que l’obligation engage l’agent PAw (self), mais que le consentement est une action de M. Pignon. L’agent PAw devra donc, dans sa couche cognitive de planification, tout mettre en œuvre pour que M. Pignon donne son consentement dans les temps (faute de quoi c’est bien self, et pas M. Pignon, qui se trouvera en violation de la norme).

date(δ) ∧ F            δ perform(self, ProcessID)

owner(ProcessID, Account, pignon) dataType(ProcessID, Account,

Ecom.Payment.Bank.PayerAccountNumber)

→ Ob^{wPignonContract}_self (consent(pignon, selfProcessID), δ)

(4.84)

4.3.3.4 Exemple sur l’axe ✭✭ Mise `a jour ✮✮

Extrait du r`eglement int´erieur du groupe W : ✭✭ Il est obligatoire de fournir aux clients un moyen de communication permettant de faire valoir leur droit de rectification des donn´ees personnelles les concernant. ✮✮

Cette norme traite `a la fois de l’axe ✭✭ Information ✮✮ et de l’axe ✭✭ Modification ✮✮. Elle illustre bien le type de traitement superficiel des normes en mati`ere de contrˆole des donn´ees par leurs propri´etaires qui a notamment ´et´e valoris´e en France depuis 1978. La formulation de la norme, exempte de toute notion temporelle, en devient ambigu¨e : quelle est l’´el´ement d´eclencheur de l’obligation, sa condition d’application ? En fait, `a quel moment le client doit-il ˆetre inform´e ? Dans la traduction de cette norme, nous choisissons de lever cette ambigu¨ıt´e afin de permettre `

a un agent PAw de mettre en place un plan d’action de mani`ere d´eterministe. Nous d´ecidons d’interpr´eter cette norme comme une obligation d’informer le client avant de lui r´eclamer une donn´ee personnelle29.

Encore une fois, cette norme peut ˆetre vue soit comme une interdiction de r´eclamer une donn´ee au client sans l’avoir inform´e de l’agent `a contacter en cas de requˆete de mise `a jour (4.85), soit comme une obligation d’informer le client avant un traitement d´ej`a programm´e, si

28

Le type de donn´ee utilis´ee ici (comme dans certains autres exemples) est d´ecrit en utilisant la transcription en sch´ema de donn´ees P3P du langage ECML, propos´ee par le W3C [Wor99].

29

On pourrait ´egalement fonder la condition d’application sur la transmission effective de l’information par le client, mais l’esprit des r´eglementations en Europe et en France va dans le sens d’une information de l’utilisateur pr´ealable `a toute collecte.

cela n’a pas encore ´et´e fait (4.86).

H⁻¬informContact(self, Client, ProcessID, Contact)

→ F or_self^wGroupRegrequest(self, Client, ProcessID, DatatType, DataID) ^(4.85) date(δ)

F (δ ∧ request(self, Client, ProcessID, DatatType, DataID)) H⁻¬informContact(self, Client, ProcessID, Contact)           

→ Ob^wGroupReg_self (informContact(self,

Client, ProcessID, Contact), δ) ^(4.86)

4.3.3.5 Exemple sur l’axe ✭✭ Justification ✮✮

Ordre direct du directeur de la branche ✭✭ Syldavie ✮✮ : ✭✭ Vous n’ˆetes pas autoris´e `a utiliser votre e-mail professionnel pour des jeux en ligne. ✮✮

La norme exprim´ee ici peut se voir soit comme une interdiction de transmettre son e-mail `a un tiers mettant en œuvre un service, soit comme l’interdiction de mettre en place un tel service. Ici il nous semble que le chef de service interdit `a ses subordonn´es d’utiliser de tels services existant sur Internet avec leurs donn´ees professionnelles, c’est donc sur le pr´edicat performatif tell que portera l’interdiction, ici ind´ependante de toute notion temporelle.

dataType(GameID, Email, user.business-info.online.email)   actionType(GameID, gaming) ∨ actionType(GameID, gambling)                 

→ F or_self^wSylChairtell(self,

ThirdParty, GameID, Email)

(4.87) 4.3.3.6 Exemple sur l’axe ✭✭ Transmission ✮✮

Extrait du r`eglement int´erieur du groupe W : ✭✭ Il est interdit de vendre les adresses de courrier ´electronique personnelles de nos clients `a la soci´et´e MarxBros Inc. ✮✮

Dans ce cas ´egalement on se trouve devant une norme ind´ependante de toute notion tempo-relle. Nous ferons donc en sorte de pouvoir d´eduire des interdictions imm´ediates, comme dans le cas de l’exemple pr´ec´edent. Pour rappel, le concept de transmission des informations `a la soci´et´e tierce se mod´elise en DLP par une mise en relation de deux donn´ees utilis´ees dans deux traitements diff´erents via le pr´edicat performatif forward.

Un souci d’interpr´etation demeure, celui de la notion de ✭✭ client ✮✮. En effet, le langage DLP ne permet pas d’associer une formule `a cette s´emantique. D’une mani`ere g´en´erale, l’expression de normes tr`es d´ependantes de notions li´ees aux sp´ecificit´e d’un sc´enario n´ecessite de se reposer sur des ontologies ad hoc et d’´etendre le langage de pr´edicats pour les repr´esenter. Nous supposerons donc ici que le sch´ema propositionnel Client repr´esente l’ensemble des propositions d´ecrivant les agents identifi´es comme des clients, et ce par des moyens externes `a DLP.

responsible(self, Process1) responsible(marxBros, Process2) dataType(Process1, Email1,

user.home-info.online.email) owner(Process1, Email1, Client)

          

→ F or^wGroupReg_self forward(Process1, Email1,

127 Utilisation de la logique DLP

4.3.3.7 Exemple sur l’axe ✭✭ R´etention ✮✮

Extrait du code du commerce syldave : ✭✭ Il est interdit de conserver le num´ero de carte de cr´edit d’un tiers plus d’une semaine apr`es la transaction pour laquelle elle a ´et´e utilis´ee. ✮✮

Cette norme est relativement simple `a traiter. La mise en œuvre d’un traitement d´eclenche simplement une obligation avec ´ech´eance de d´etruire (d’oublier) une donn´ee personnelle30. On remarquera que comme la norme parle de ✭✭ tiers ✮✮, il est n´ecessaire de s’assurer que ce n’est pas l’agent lui-mˆeme qui est le propri´etaire de l’information `a supprimer. En effet, dans ce cas, l’obligation de suppression ne s’appliquerait pas.

perform(self, ProcessID) date(δ)

X^7∗24+1δ

owner(ProcessID, CreditCard, Tiers) ¬owner(ProcessID, CreditCard, self) dataType(ProcessID, CreditCard, Ecom.Payment.Card.Number)                   

→ Ob^syldavianLaw_self (forget(self,

ProcessID, CreditCard), δ) ^(4.89)

Il nous faut ´egalement consid´erer le cas de figure dans lequel la base de norme a ´et´e r´einitialis´ee r´ecemment, mais qu’un traitement utilisant le num´ero de carte de cr´edit d’un client a ´et´e r´ealis´e il y a moins d’une semaine. Dans ce cas, nous produisons une nouvelle obligation avec ´ech´eance, sur la base d’une date situ´ee une semaine apr`es ledit traitement :

date(δ)

P (perform(self, ProcessID) ∧ X^7∗24+1δ) F δ

owner(ProcessID, CreditCard, Tiers) ¬owner(ProcessID, CreditCard, self) dataType(ProcessID, CreditCard, Ecom.Payment.Card.Number)                   

→ Ob^syldavianLaw_self (forget(self,

ProcessID, CreditCard), δ) ^(4.90)

Enfin, si le traitement a eu lieu il y a plus d’une semaine, toute violation ayant pu survenir, avant ou apr`es une ´eventuelle r´einitialisation de la base de normes, a d´ej`a ´et´e stigmatis´ee dans la base de croyances de l’agent PAw.

Dans le document Agents utilisateurs pour la protection des données personnelles : modélisation logique et outils informatiques (Page 142-148)