Accord de sous-traitance (art. 28 RGPD) — l'Éditeur / Client

Brouillon, à relire par un avocat. Ce n'est pas un avis juridique. Rédaction Produit, ELF-130, 24/10/2026. Faits vérifiés sur origin/main (4008dda).

Ce document reprend les clauses contractuelles types de la Commission européenne, décision d'exécution (UE) 2021/915 du 4 juin 2021 (JOUE L 199/18 du 7.6.2021), module responsable du traitement → sous-traitant. Le texte des clauses 1 à 10 ci-dessous est copié de la version française publiée au Journal officiel (récupérée sur le Cellar de l'Office des publications), sans modification : seuls les choix d'options et les annexes sont remplis, comme le permet la clause 2 a). Les annexes portent les numéros I à IV (vérifié dans le texte officiel : I liste des parties, II description du traitement, III mesures techniques et organisationnelles, IV liste des sous-traitants ultérieurs).

Choix d'options (à reporter dans la version finale)

Points à trancher avant mise en ligne

1. Identité de l'Éditeur (annexe I) : raison sociale, SIREN, siège. Le nom retenu pour le Service est NACscale ; la société doit être immatriculée sous le même nom le 4/11/2026 (ELF-217), sa raison sociale exacte reste inconnue. Question posée à elfayafi sur ELF-115, sans réponse. Rien n'est inventé.

2. Préavis de la clause 7.7 a) : 30 jours proposés, non arbitrés.

3. Clause 10 d) et LCEN : à la fin du contrat, le sous-traitant supprime ou restitue les données « selon le choix » du responsable. Or le Client doit lui-même conserver 12 mois les journaux de connexion (art. L34-1 CPCE). Le Client doit donc récupérer l'export signé avant la suppression. L'outil de clôture est en production depuis le 24/10/2026 (ADR-0019, ELF-154), par l'API seulement : export de clôture signé disponible 30 jours, puis suppression totale et preuve de suppression, certificat sur demande (annexe III, §16). Restent à trancher : le délai du certificat (15 jours proposés), la confirmation de l'option (A) par l'avocat (annexe III, §16), et la durée des sauvegardes, qui s'ajoute aux 30 jours (annexe III, §5).

4. MSP : un MSP qui gère des sous-tenants est sous-traitant de son client, l'Éditeur devient sous-traitant ultérieur. Ce schéma n'est pas couvert par ce modèle ; à relire.

5. Annexes III et IV : insérées (Secu, ELF-134 ; SRE, ELF-135). Restent en [À COMPLÉTER] : le relais SMTP de production (non identifié, annexe IV non signable sans lui), les contacts des sous-traitants, le délai de notification de violation (48 h proposé) et la durée des sauvegardes.

Texte des clauses (reproduit sans modification)

SECTION I

Clause 1

Objet et champ d’application

• a) Les présentes clauses contractuelles types (ci-après les «clauses») ont pour objet de garantir la conformité avec [choisir l’option qui convient: OPTION 1: l’article 28, paragraphes 3 et 4, du règlement (UE) 2016/679 du Parlement européen et du Conseil du 27 avril 2016 relatif à la protection des personnes physiques à l’égard du traitement des données à caractère personnel et à la libre circulation de ces données, et abrogeant la directive 95/46/CE (règlement général sur la protection des données]/[OPTION 2: l’article 29, paragraphes 3 et 4, du règlement (UE) 2018/1725 du Parlement européen et du Conseil du 23 octobre 2018 relatif à la protection des personnes physiques à l’égard du traitement des données à caractère personnel par les institutions, organes et organismes de l’Union et à la libre circulation de ces données, et abrogeant le règlement (CE) n o 45/2001 et la décision n o 1247/2002/CE].

• b) Les responsables du traitement et les sous-traitants énumérés à l’annexe I ont accepté ces clauses afin de garantir le respect des dispositions de l’article 28, paragraphes 3 et 4, du règlement (UE) 2016/679 et/ou des dispositions de l’article 29, paragraphes 3 et 4, du règlement (UE) 2018/1725.

• c) Les présentes clauses s’appliquent au traitement des données à caractère personnel tel que décrit à l’annexe II.

• d) Les annexes I à IV font partie intégrante des clauses.

• e) Les présentes clauses sont sans préjudice des obligations auxquelles le responsable du traitement est soumis en vertu du règlement (UE) 2016/679 et/ou du règlement (UE) 2018/1725.

• f) Les clauses ne suffisent pas à elles seules pour assurer le respect des obligations relatives aux transferts internationaux conformément au chapitre V du règlement (UE) 2016/679 et/ou du règlement (UE) 2018/1725.

Clause 2

Invariabilité des clauses

• a) Les parties s’engagent à ne pas modifier les clauses, sauf en ce qui concerne l’ajout d’informations aux annexes ou la mise à jour des informations qui y figurent.

• b) Les parties ne sont pour autant pas empêchées d’inclure les clauses contractuelles types définies dans les présentes clauses dans un contrat plus large, ni d’ajouter d’autres clauses ou des garanties supplémentaires, à condition que celles-ci ne contredisent pas, directement ou indirectement, les clauses ou qu’elles ne portent pas atteinte aux libertés et droits fondamentaux des personnes concernées.

Clause 3

Interprétation

• a) Lorsque des termes définis respectivement dans le règlement (UE) 2016/679 ou dans le règlement (UE) 2018/1725 figurent dans les clauses, ils s’entendent comme dans le règlement en question.

• b) Les présentes clauses doivent être lues et interprétées à la lumière des dispositions du règlement (UE) 2016/679 et du règlement (UE) 2018/1725 respectivement.

• c) Les présentes clauses ne doivent pas être interprétées d’une manière contraire aux droits et obligations prévus par le règlement (UE) 2016/679 / le règlement (UE) 2018/1725 ou d’une manière qui porte atteinte aux libertés ou droits fondamentaux des personnes concernées.

Clause 4

Hiérarchie En cas de contradiction entre les présentes clauses et les dispositions des accords connexes qui existent entre les parties au moment où les présentes clauses sont convenues ou qui sont conclus ultérieurement, les présentes clauses prévaudront.

Clause 5 — Facultative

Clause d’amarrage

• a) Toute entité qui n’est pas partie aux présentes clauses peut, avec l’accord de toutes les parties, y adhérer à tout moment, en qualité soit de responsable du traitement soit de sous-traitant, en complétant les annexes et en signant l’annexe I.

• b) Une fois que les annexes mentionnées au point a) sont complétées et signées, l’entité adhérente est considérée comme une partie aux présentes clauses et jouit des droits et est soumise aux obligations d’un responsable du traitement ou d’un sous-traitant, conformément à sa désignation à l’annexe I.

• c) Les présentes clauses ne créent pour la partie adhérente aucun droit ni aucune obligation pour la période précédant l’adhésion.

SECTION II

OBLIGATIONS DES PARTIES

Clause 6

Description du ou des traitements Les détails des opérations de traitement, et notamment les catégories de données à caractère personnel et les finalités du traitement pour lesquelles les données à caractère personnel sont traitées pour le compte du responsable du traitement, sont précisés à l’annexe II.

Clause 7

Obligations des parties

7.1. Instructions

• a) Le sous-traitant ne traite les données à caractère personnel que sur instruction documentée du responsable du traitement, à moins qu’il ne soit tenu d’y procéder en vertu du droit de l’Union ou du droit de l’État membre auquel il est soumis. Dans ce cas, le sous-traitant informe le responsable du traitement de cette obligation juridique avant le traitement, sauf si la loi le lui interdit pour des motifs importants d’intérêt public. Des instructions peuvent également être données ultérieurement par le responsable du traitement pendant toute la durée du traitement des données à caractère personnel. Ces instructions doivent toujours être documentées.

• b) Le sous-traitant informe immédiatement le responsable du traitement si, selon lui, une instruction donnée par le responsable du traitement constitue une violation du règlement (UE) 2016/679 / du règlement (UE) 2018/1725 ou d'autres dispositions du droit de l'Union ou du droit des États membres relatives à la protection des données.

7.2. Limitation de la finalité Le sous-traitant traite les données à caractère personnel uniquement pour la ou les finalités spécifiques du traitement, telles que définies à l’annexe II, sauf instruction complémentaire du responsable du traitement.

7.3. Durée du traitement des données à caractère personnel Le traitement par le sous-traitant n’a lieu que pendant la durée précisée à l’annexe II.

7.4. Sécurité du traitement

• a) Le sous-traitant met au moins en œuvre les mesures techniques et organisationnelles précisées à l’annexe III pour assurer la sécurité des données à caractère personnel. Figure parmi ces mesures la protection des données contre toute violation de la sécurité entraînant, de manière accidentelle ou illicite, la destruction, la perte, l'altération, la divulgation non autorisée de données à caractère personnel ou l'accès non autorisé à de telles données (violation de données à caractère personnel). Lors de l’évaluation du niveau de sécurité approprié, les parties tiennent dûment compte de l'état des connaissances, des coûts de mise en œuvre et de la nature, de la portée, du contexte et des finalités du traitement, ainsi que des risques pour les personnes concernées.

• b) Le sous-traitant n’accorde aux membres de son personnel l’accès aux données à caractère personnel faisant l’objet du traitement que dans la mesure strictement nécessaire à l’exécution, à la gestion et au suivi du contrat. Le sous-traitant veille à ce que les personnes autorisées à traiter les données à caractère personnel s'engagent à respecter la confidentialité ou soient soumises à une obligation légale appropriée de confidentialité.

7.5. Données sensibles Si le traitement porte sur des données à caractère personnel révélant l'origine raciale ou ethnique, les opinions politiques, les convictions religieuses ou philosophiques ou l'appartenance syndicale, ainsi que des données génétiques ou des données biométriques aux fins d'identifier une personne physique de manière unique, des données concernant la santé ou des données concernant la vie sexuelle ou l'orientation sexuelle d'une personne physique, ou des données relatives aux condamnations pénales et aux infractions («données sensibles»), le sous-traitant applique des limitations spécifiques et/ou des garanties supplémentaires.

7.6. Documentation et conformité

• a) Les parties doivent pouvoir démontrer la conformité avec les présentes clauses.

• b) Le sous-traitant traite de manière rapide et adéquate les demandes du responsable du traitement concernant le traitement des données conformément aux présentes clauses.

• c) Le sous-traitant met à la disposition du responsable du traitement toutes les informations nécessaires pour démontrer le respect des obligations énoncées dans les présentes clauses et découlant directement du règlement (UE) 2016/679 et/ou du règlement (UE) 2018/1725. À la demande du responsable du traitement, le sous-traitant permet également la réalisation d’audits des activités de traitement couvertes par les présentes clauses et y contribue, à intervalles raisonnables ou en présence d’indices de non-conformité. Lorsqu’il décide d’un examen ou d’un audit, le responsable du traitement peut tenir compte des certifications pertinentes en possession du sous-traitant.

• d) Le responsable du traitement peut décider de procéder lui-même à l’audit ou de mandater un auditeur indépendant. Les audits peuvent également comprendre des inspections dans les locaux ou les installations physiques du sous-traitant et sont, le cas échéant, effectués moyennant un préavis raisonnable.

• e) Les parties mettent à la disposition de l’autorité de contrôle compétente/des autorités de contrôle compétentes, dès que celles-ci en font la demande, les informations énoncées dans la présente clause, y compris les résultats de tout audit.

7.7. Recours à des sous-traitants ultérieurs

• a) OPTION 1: AUTORISATION SPÉCIFIQUE PRÉALABLE: le sous-traitant n’est pas autorisé à sous-traiter à un sous-traitant ultérieur les opérations de traitement qu’il effectue pour le compte du responsable du traitement en vertu des présentes clauses sans l’autorisation écrite spécifique préalable du responsable du traitement. Le sous-traitant soumet la demande d’autorisation spécifique au moins [PRÉCISER LA DURÉE] avant le recrutement du sous-traitant ultérieur en question, ainsi que les informations nécessaires pour permettre au responsable du traitement de prendre une décision au sujet de l’autorisation. La liste des sous-traitants ultérieurs autorisés par le responsable du traitement figure à l’annexe IV, que les parties tiennent à jour. OPTION 2: AUTORISATION ÉCRITE GÉNÉRALE: le sous-traitant dispose de l’autorisation générale du responsable du traitement pour ce qui est du recrutement de sous-traitants ultérieurs sur la base d’une liste convenue. Le sous-traitant informe spécifiquement par écrit le responsable du traitement de tout projet de modification de cette liste par l’ajout ou le remplacement de sous-traitants ultérieurs au moins [PRÉCISER LA DURÉE] à l’avance, donnant ainsi au responsable du traitement suffisamment de temps pour pouvoir s’opposer à ces changements avant le recrutement du ou des sous-traitants ultérieurs concernés. Le sous-traitant fournit au responsable du traitement les informations nécessaires pour lui permettre d’exercer son droit d’opposition.

• b) Lorsque le sous-traitant recrute un sous-traitant ultérieur pour mener des activités de traitement spécifiques (pour le compte du responsable du traitement), il le fait au moyen d’un contrat qui impose au sous-traitant ultérieur, en substance, les mêmes obligations en matière de protection des données que celles imposées au sous-traitant en vertu des présentes clauses. Le sous-traitant veille à ce que le sous-traitant ultérieur respecte les obligations auxquelles il est lui-même soumis en vertu des présentes clauses et du règlement (UE) 2016/679 et/ou du règlement (UE) 2018/1725.

• c) À la demande du responsable du traitement, le sous-traitant lui fournit une copie de ce contrat conclu avec le sous-traitant ultérieur et de toute modification qui y est apportée ultérieurement. Dans la mesure nécessaire à la protection des secrets d’affaires ou d’autres informations confidentielles, y compris les données à caractère personnel, le sous-traitant peut expurger le texte du contrat avant d’en diffuser une copie.

• d) Le sous-traitant demeure pleinement responsable, à l’égard du responsable du traitement, de l’exécution des obligations du sous-traitant ultérieur conformément au contrat conclu avec le sous-traitant ultérieur. Le sous-traitant informe le responsable du traitement de tout manquement du sous-traitant ultérieur à ses obligations contractuelles.

• e) Le sous-traitant convient avec le sous-traitant ultérieur d’une clause du tiers bénéficiaire selon laquelle — dans le cas où le sous-traitant a matériellement disparu, a cessé d’exister en droit ou est devenu insolvable — le responsable du traitement a le droit de résilier le contrat conclu avec le sous-traitant ultérieur et de donner instruction au sous-traitant ultérieur d’effacer ou de renvoyer les données à caractère personnel.

7.8. Transferts internationaux

• a) Tout transfert de données vers un pays tiers ou une organisation internationale par le sous-traitant n’est effectué que sur la base d’instructions documentées du responsable du traitement ou afin de satisfaire à une exigence spécifique du droit de l’Union ou du droit de l’État membre à laquelle le sous-traitant est soumis et s’effectue conformément au chapitre V du règlement (UE) 2016/679 ou du règlement (UE) 2018/1725.

• b) Le responsable du traitement convient que lorsque le sous-traitant recrute un sous-traitant ultérieur conformément à la clause 7.7 pour mener des activités de traitement spécifiques (pour le compte du responsable du traitement) et que ces activités de traitement impliquent un transfert de données à caractère personnel au sens du chapitre V du règlement (UE) 2016/679, le sous-traitant et le sous-traitant ultérieur peuvent garantir le respect du chapitre V du règlement (UE) 2016/679 en utilisant les clauses contractuelles types adoptées par la Commission sur la base de l’article 46, paragraphe 2, du règlement (UE) 2016/679, pour autant que les conditions d’utilisation de ces clauses contractuelles types soient remplies.

Clause 8

Assistance au responsable du traitement

• a) Le sous-traitant informe sans délai le responsable du traitement de toute demande qu’il a reçue de la part de la personne concernée. Il ne donne pas lui-même suite à cette demande, à moins que le responsable du traitement des données ne l’y ait autorisé.

• b) Le sous-traitant prête assistance au responsable du traitement pour ce qui est de remplir l’obligation qui lui incombe de répondre aux demandes des personnes concernées d’exercer leurs droits, en tenant compte de la nature du traitement. Dans l’exécution de ses obligations conformément aux points a) et b), le sous-traitant se conforme aux instructions du responsable du traitement.

• c) Outre l’obligation incombant au sous-traitant d’assister le responsable du traitement en vertu de la clause 8, point b), le sous-traitant aide en outre le responsable du traitement à garantir le respect des obligations suivantes, compte tenu de la nature du traitement et des informations dont dispose le sous-traitant: 1) l’obligation de procéder à une évaluation de l’incidence des opérations de traitement envisagées sur la protection des données à caractère personnel («analyse d’impact relative à la protection des données») lorsqu’un type de traitement est susceptible de présenter un risque élevé pour les droits et libertés des personnes physiques; 2) l’obligation de consulter l'autorité de contrôle compétente/les autorités de contrôle compétentes préalablement au traitement lorsqu'une analyse d'impact relative à la protection des données indique que le traitement présenterait un risque élevé si le responsable du traitement ne prenait pas de mesures pour atténuer le risque; 3) l’obligation de veiller à ce que les données à caractère personnel soient exactes et à jour, en informant sans délai le responsable du traitement si le sous-traitant apprend que les données à caractère personnel qu’il traite sont inexactes ou sont devenues obsolètes; 4) les obligations prévues à [OPTION 1] l’article 32 du règlement (UE) 2016/679 / [OPTION 2] aux articles 33, 36 à 38 du règlement (UE) 2018/1725.

• d) Les parties définissent à l’annexe III les mesures techniques et organisationnelles appropriées par lesquelles le sous-traitant est tenu de prêter assistance au responsable du traitement dans l’application de la présente clause, ainsi que la portée et l’étendue de l’assistance requise.

Clause 9

Notification de violations de données à caractère personnel En cas de violation de données à caractère personnel, le sous-traitant coopère avec le responsable du traitement et lui prête assistance aux fins de la mise en conformité avec les obligations qui lui incombent en vertu des articles 33 et 34 du règlement (UE) 2016/679 ou des articles 34 et 35 du règlement (UE) 2018/1725, selon celui qui est applicable, en tenant compte de la nature du traitement et des informations dont dispose le sous-traitant.

9.1. Violation de données en rapport avec des données traitées par le responsable du traitement En cas de violation de données à caractère personnel en rapport avec des données traitées par le responsable du traitement, le sous-traitant prête assistance au responsable du traitement:

• a) aux fins de la notification de la violation de données à caractère personnel à l’autorité de contrôle compétente/aux autorités de contrôle compétentes, dans les meilleurs délais après que le responsable du traitement en a eu connaissance, le cas échéant (sauf si la violation de données à caractère personnel est peu susceptible d'engendrer un risque pour les droits et libertés des personnes physiques);

• b) aux fins de l’obtention des informations suivantes qui, conformément à [OPTION 1] l’article 33, paragraphe 3, du règlement (UE) 2016/679 / [OPTION 2] l’article 34, paragraphe 3, du règlement (UE) 2018/1725, doivent figurer dans la notification du responsable du traitement, et inclure, au moins: 1) la nature des données à caractère personnel, y compris, si possible, les catégories et le nombre approximatif de personnes concernées par la violation et les catégories et le nombre approximatif d’enregistrements de données à caractère personnel concernés; 2) les conséquences probables de la violation de données à caractère personnel; 3) les mesures prises ou les mesures que le responsable du traitement propose de prendre pour remédier à la violation de données à caractère personnel, y compris, le cas échéant, les mesures pour en atténuer les éventuelles conséquences négatives. Lorsque, et dans la mesure où, il n’est pas possible de fournir toutes les informations en même temps, la notification initiale contient les informations disponibles à ce moment-là et, à mesure qu’elles deviennent disponibles, des informations supplémentaires sont communiquées par la suite dans les meilleurs délais;

• c) aux fins de la satisfaction, conformément à [OPTION 1] l’article 34 du règlement (UE) 2016/679 / [OPTION 2] l’article 35 du règlement (UE) 2018/1725, de l’obligation de communiquer dans les meilleurs délais la violation de données à caractère personnel à la personne concernée, lorsque la violation de données à caractère personnel est susceptible d’engendrer un risque élevé pour les droits et libertés des personnes physiques.

9.2. Violation de données en rapport avec des données traitées par le sous-traitant En cas de violation de données à caractère personnel en rapport avec des données traitées par le sous-traitant, celui-ci en informe le responsable du traitement dans les meilleurs délais après en avoir pris connaissance. Cette notification contient au moins:

• a) une description de la nature de la violation constatée (y compris, si possible, les catégories et le nombre approximatif de personnes concernées par la violation et d'enregistrements de données à caractère personnel concernés);

• b) les coordonnées d’un point de contact auprès duquel des informations supplémentaires peuvent être obtenues au sujet de la violation de données à caractère personnel;

• c) ses conséquences probables et les mesures prises ou les mesures qu’il est proposé de prendre pour remédier à la violation, y compris pour en atténuer les éventuelles conséquences négatives. Lorsque, et dans la mesure où, il n’est pas possible de fournir toutes les informations en même temps, la notification initiale contient les informations disponibles à ce moment-là et, à mesure qu’elles deviennent disponibles, des informations supplémentaires sont communiquées par la suite dans les meilleurs délais. Les parties définissent à l’annexe III tous les autres éléments que le sous-traitant doit communiquer lorsqu’il prête assistance au responsable du traitement aux fins de la satisfaction des obligations incombant à ce dernier en vertu [OPTION 1] des articles 33 et 34 du règlement (UE) 2016/679/[OPTION 2] des articles 34 et 35 du règlement (UE) 2018/1725.

SECTION III

DISPOSITIONS FINALES

Clause 10

Non-respect des clauses et résiliation

• a) Sans préjudice des dispositions du règlement (UE) 2016/679 et/ou du règlement (UE) 2018/1725, en cas de manquement du sous-traitant aux obligations qui lui incombent en vertu des présentes clauses, le responsable du traitement peut donner instruction au sous-traitant de suspendre le traitement des données à caractère personnel jusqu’à ce que ce dernier se soit conformé aux présentes clauses ou jusqu’à ce que le contrat soit résilié. Le sous-traitant informe rapidement le responsable du traitement s’il n’est pas en mesure de se conformer aux présentes clauses, pour quelque raison que ce soit.

• b) Le responsable du traitement est en droit de résilier le contrat dans la mesure où il concerne le traitement de données à caractère personnel conformément aux présentes clauses si: 1) le traitement de données à caractère personnel par le sous-traitant a été suspendu par le responsable du traitement conformément au point a) et le respect des présentes clauses n’est pas rétabli dans un délai raisonnable et, en tout état de cause, dans un délai d’un mois à compter de la suspension; 2) le sous-traitant est en violation grave ou persistante des présentes clauses ou des obligations qui lui incombent en vertu du règlement (UE) 2016/679 et/ou du règlement (UE) 2018/1725; 3) le sous-traitant ne se conforme pas à une décision contraignante d’une juridiction compétente ou de l’autorité de contrôle compétente/des autorités de contrôle compétentes concernant les obligations qui lui incombent en vertu des présentes clauses ou du règlement (UE) 2016/679 et/ou du règlement (UE) 2018/1725.

• c) Le sous-traitant est en droit de résilier le contrat dans la mesure où il concerne le traitement de données à caractère personnel en vertu des présentes clauses lorsque, après avoir informé le responsable du traitement que ses instructions enfreignent les exigences juridiques applicables conformément à la clause 7.1, point b), le responsable du traitement insiste pour que ses instructions soient suivies.

• d) À la suite de la résiliation du contrat, le sous-traitant supprime, selon le choix du responsable du traitement, toutes les données à caractère personnel traitées pour le compte du responsable du traitement et certifie auprès de celui-ci qu’il a procédé à cette suppression, ou renvoie toutes les données à caractère personnel au responsable du traitement et détruit les copies existantes, à moins que le droit de l’Union ou le droit national n’impose de les conserver plus longtemps. Le sous-traitant continue de veiller à la conformité aux présentes clauses jusqu’à la suppression ou à la restitution des données.

ANNEXE I — Liste des parties

Responsable(s) du traitement : le Client, personne identifiée à son inscription au service (organisme exploitant le réseau WiFi).

1. Nom : [renseigné à l'inscription en ligne : raison sociale du tenant] Adresse : [renseignée à l'inscription] Nom, fonction et coordonnées de la personne de contact : [administrateur propriétaire du tenant] ; délégué à la protection des données : [le cas échéant, renseigné par le Client] Signature et date d'adhésion : [case à cocher et version horodatée à l'inscription ; pour un premier pilote : signature du PDF]

Sous-traitant(s) :

1. Nom : [À COMPLÉTER : raison sociale de l'Éditeur] Adresse : [À COMPLÉTER : siège social] SIREN : [À COMPLÉTER] Nom, fonction et coordonnées de la personne de contact : [À COMPLÉTER : contact protection des données] Signature et date d'adhésion : [À COMPLÉTER]

ANNEXE II — Description du traitement

Source de chaque affirmation : origin/main 4008dda. Ce qui n'est pas observé est marqué « non vérifié ».

Catégories de personnes concernées

1. Visiteurs du portail captif WiFi du Client (personnes qui se connectent).

2. Administrateurs et collaborateurs du Client qui utilisent la console (propriétaires, administrateurs, lecteurs, et administrateurs d'un MSP agissant pour le Client).

3. Utilisateurs et appareils 802.1X du Client, uniquement si le Client active ce module. Le module est gaté par un drapeau (RADSEC_ENABLED, défaut false) et n'a pas été observé sur matériel physique (docs/roadmap.md). Il n'entre dans le service que s'il est activé pour le Client et décrit comme disponible dans la documentation.

Catégories de données à caractère personnel traitées

Visiteurs (journaux de connexion, connection_logs) : identité déclarée (adresse e-mail, ou identifiant fourni par un fournisseur d'identité, ou numéro de téléphone pour la méthode SMS — stockage de ce numéro dans l’identité chiffrée : non vérifié), adresse MAC de l'appareil, adresse IP, adresse MAC du point d'accès, site, méthode d'accès, horodatage de début et de fin, durée, volumétrie, version du consentement et horodatage du consentement (docs/architecture.md §3). L'identité en clair est chiffrée (AES-256-GCM, AAD = tenant) ; son empreinte SHA-256 est scellée dans la chaîne, la valeur en clair n'y figure pas.

Réponses aux champs personnalisés du portail (si le Client en configure) : au plus 10 champs par site (texte, liste, case), réponses chiffrées, rattachées à l'entrée du journal (docs/architecture.md l. 144). Contenu fixé par le Client, voir la limite ci-dessous.

Appareils reconnus (si l'option « reconnexion » est activée par site) : pseudonyme HMAC de l'adresse MAC, empreinte du secret d'appareil, identité de la visite d'origine chiffrée (docs/architecture.md §3, ELF-83).

Administrateurs : adresse e-mail, mot de passe haché (argon2id), secret TOTP chiffré, codes de récupération hachés, adresse IP et agent utilisateur des sessions (docs/architecture.md §2).

802.1X (si activé) : adresse MAC, nom du sujet du certificat, groupe d'annuaire du Client (Entra ID), diagnostics d'échec d'authentification agrégés par jour (comptes par site × méthode × issue ; bornes et compteurs par appareil) (docs/architecture.md §3, docs/diagnostic-auth.md).

Données sensibles et garanties. Le service ne vise aucune donnée sensible (art. 9 et 10 du RGPD). Le Client s'interdit d'en collecter par les champs personnalisés : catégories particulières de données, NIR, données bancaires, condamnations et infractions, même dans un champ de texte libre. Garanties : réponses chiffrées au repos, export séparé réservé aux rôles propriétaire et administrateur, isolation par locataire (RLS FORCE), finalité obligatoire affichée au visiteur dès qu'un champ existe. Limite à lire telle quelle : le produit ne détecte pas le contenu interdit (les réponses sont chiffrées et non analysées) ; l'interdiction repose sur l'engagement du Client. (Projet de clause X.1 à X.6 du ELF-106 à intégrer au contrat principal ou aux CGV, voir note-avocat.)

Nature du traitement. Hébergement et exploitation d'un service SaaS : collecte via le portail captif, enregistrement chiffré, chaînage cryptographique des journaux (chaque entrée est scellée par une empreinte SHA-256 qui inclut l'empreinte de la précédente), consultation en console et par l'API, export (CSV ; export de conformité signé Ed25519 avec manifeste), pseudonymisation sur demande, purge à l'échéance.

Finalités pour lesquelles les données sont traitées pour le compte du Client

1. Fournir l'accès WiFi invité et tenir le registre des connexions que le Client doit conserver en application de l'art. L34-1 du CPCE.

2. Prouver l'intégrité des journaux (hash-chain, export signé).

3. Recueillir et prouver le consentement du visiteur aux conditions du Client.

4. Authentifier les administrateurs de la console et sécuriser l'accès.

5. Si activé : authentification 802.1X des appareils et utilisateurs du Client, et diagnostic des échecs.

L'Éditeur ne traite ces données pour aucune finalité propre au-delà de la fourniture du service, de la sécurité et de la métrologie technique sans identité (docs/architecture.md, « pas de télémétrie externe » : CLAUDE.md).

Durée du traitement

Effacement et pseudonymisation. Sur demande de la personne concernée transmise par le Client, l'Éditeur pseudonymise : la valeur chiffrée de l'identité est supprimée, son empreinte scellée demeure, de sorte que la chaîne reste vérifiable pendant la période de rétention légale. Ce n'est pas une anonymisation : l'adresse MAC, l'adresse IP et l'empreinte de l'identité restent dans l'entrée jusqu'à la purge à 12 mois (la conservation d'un an est une obligation légale du Client). L'empreinte n'est pas clée : elle peut être retrouvée par qui connaît déjà l'identité. Point à relire par l'avocat.

Pour le traitement par les sous-traitants ultérieurs : objet, nature et durée sont ceux décrits ci-dessus, limités à l'hébergement et à l'exécution du service ; détails par sous-traitant en annexe IV.

ANNEXE III — Mesures techniques et organisationnelles

Source : document annexe-iii (Secu, ELF-134), constats sur origin/main @ 4008dda = production. Les écarts connus (sauvegarde…) sont volontairement exclus de ce texte contractuel : voir annexe-iii § « Écarts connus » et note-avocat. Les valeurs entre crochets restent à valider. Mise à jour du 24/10/2026 (CEO, d'après ELF-140) : formulations des §2.2, §4, §9, §13 et §16 alignées sur l'état réel ; les notes de rédaction donnent le texte qui les remplacera une fois chaque écart corrigé en production. Mise à jour du 24/10/2026, révision 4 (fusion de #493, 80a4297) : la procédure de violation est en vigueur, et le §13 la décrit (E5 levé). Le §9 et la note du §16 citent ADR-0018 et ADR-0019. Mise à jour du 25/10/2026, révision 5 (ELF-190) : le second facteur est obligatoire en production pour owner et admin connectés par mot de passe depuis le 24/10/2026 à 20:34:47 UTC (#497, déployé au commit f2dc846). Date d'effet contractuelle : 25/10/2026 à 08:35 UTC, une fois expirées les sessions de 12 h ouvertes avant la bascule. Le §2.2 le décrit (E3 levé), et ses références au code suivent 36bd1cf. Le §16 décrit la clôture de tenant en production depuis le 24/10/2026, par l'API (#516, ADR-0019 et son amendement) : E6 levé côté API, la console suivra (ELF-155).

Description des mesures

Les mesures ci-dessous s'appliquent aux données personnelles traitées par l'Éditeur (le sous-traitant) pour le compte du Client (le responsable du traitement) dans le cadre du Service NACscale : portail captif WiFi invité et, lorsqu'il est activé, contrôle d'accès réseau 802.1X.

1. Pseudonymisation et chiffrement des données à caractère personnel

1.1 Chiffrement au repos. Les données suivantes sont chiffrées dans la base de données avec l'algorithme AES-256-GCM (chiffrement authentifié, nonce aléatoire de 96 bits par opération) [internal/platform/crypto/envelope.go:24-54] :

• l'identité déclarée par le visiteur du portail (adresse e-mail, code d'accès…), dans le journal de connexion [internal/compliance/service.go:127] ;

• l'identité conservée pour la reconnexion d'un appareil reconnu [internal/portal/reconnect.go:190] ;

• l'identifiant (UPN) et le nom affiché des personnes enrôlées en 802.1X via Microsoft Entra ID [internal/pki/person.go:190-194, internal/enroll/oidc.go:292-296] ;

• les réponses aux champs personnalisés du portail (voir 1.2) [internal/portal/form.go:327] ;

• le contenu des courriels en file d'envoi [internal/platform/mailq/mailq.go:56] ;

• les secrets techniques du Client : clés privées des autorités de certification et des certificats serveur, secrets RADIUS, secrets des fournisseurs d'identité, secrets TOTP, secrets de webhooks et jetons des connecteurs [internal/pki/service.go:139, internal/pki/radsec.go:100, internal/nac/clients.go:66, internal/portal/oidc.go:86, internal/network/webhookout/service.go:168, internal/network/freebox_connector.go:94].

Chaque chiffré est lié au Client : l'identifiant du Client (tenant) est utilisé comme donnée authentifiée additionnelle (AAD). Un chiffré recopié dans les données d'un autre Client ne se déchiffre pas [envelope.go:45-54].

1.2 Réponses aux champs personnalisés. Les réponses recueillies par les champs personnalisés du portail sont chiffrées en un bloc unique dont l'AAD lie le chiffré au Client, à la finalité et à l'entrée de journal à laquelle il se rattache (tenant ‖ "portal_form_answers/v1" ‖ identifiant de l'entrée). Un bloc déplacé vers une autre ligne ou une autre table ne se déchiffre plus [envelope.go:91-119, migrations/00114_portal_formulaire_personnalise.sql:10-15].

1.3 Pseudonymisation.

• Le journal de connexion conserve, à côté de l'identité chiffrée, une empreinte SHA-256 de l'identité normalisée (espaces retirés, minuscules) [internal/compliance/chain.go:49-61]. C'est cette empreinte, et non l'identité, qui est scellée dans la chaîne d'intégrité (voir 3.1).

• Les appareils reconnus du portail sont identifiés par une empreinte HMAC-SHA256 à clé de leur adresse MAC [internal/portal/returning.go:29]. Le secret de reconnexion d'un appareil n'est stocké que sous forme d'empreinte HMAC [internal/portal/reconnect.go:100].

• Les statistiques d'échec d'authentification 802.1X par appareil ne contiennent ni adresse MAC en clair, ni numéro de série, ni adresse IP. Elles utilisent une empreinte HMAC à clé de la MAC, avec une clé dérivée (HKDF) qui n'est jamais enregistrée en base [internal/authfeed/fingerprint.go:26-39, docs/architecture.md §« Statistiques d'authentification »].

• Les jetons de session, jetons d'API et codes de secours ne sont stockés que sous forme d'empreinte SHA-256 [internal/platform/crypto/token.go:24-29].

Limites, à porter à la connaissance du Client.

• L'empreinte d'identité du journal n'utilise pas de clé : toute personne qui a accès à la base peut vérifier si une adresse e-mail donnée y figure. Il s'agit d'une pseudonymisation, pas d'une anonymisation.

• L'adresse MAC, l'adresse IP de l'appareil et l'adresse MAC du point d'accès sont conservées en clair dans le journal de connexion, et scellées dans la chaîne [chain.go:26-39]. Ce sont les données techniques d'identification dont la conservation est exigée pendant un an par l'article L34-1 du CPCE. Elles ne sont ni chiffrées ni pseudonymisables pendant cette durée.

• Une seule clé maître (DATA_ENCRYPTION_KEY) chiffre les données de tous les Clients. Le cloisonnement entre Clients repose sur l'AAD, pas sur des clés séparées [envelope.go:13-18]. Une clé par Client ou un KMS externe est prévu, sans date.

Note de rédaction : contrairement à la mention de la carte, l'identité de 802.1X n'est pas une adresse MAC. Les MAC des visiteurs du portail restent en clair (point ci-dessus, cf. ELF-96). Seules les MAC des statistiques 802.1X et des appareils reconnus sont pseudonymisées.

2. Confidentialité : contrôle d'accès et cloisonnement des Clients

2.1 Cloisonnement entre Clients dans la base de données.

• Les tables métier sont soumises à la sécurité au niveau des lignes de PostgreSQL (Row-Level Security) en mode FORCE. Une ligne n'est visible et modifiable que si son tenant_id est égal au Client de la transaction en cours (exemple : migrations/00114_portal_formulaire_personnalise.sql:28-34).

• Toute requête sur une table métier passe par InTenantTx. Cette fonction ouvre une transaction, bascule sur le rôle restreint vigifi_app et fixe le Client courant pour la seule durée de la transaction [internal/platform/db/store.go:43-64].

• Le service se connecte sous un rôle PostgreSQL dédié (vigifi_login, membre de vigifi_app). Ce rôle n'est pas superutilisateur et ne peut pas contourner la RLS. En production, le service refuse de démarrer si cette posture n'est pas établie. La posture est mesurée sur les droits effectifs, pas supposée [internal/platform/db/posture.go:28-41,136-160, docs/deploy.md §« RLS et posture d'isolation »].

• Constaté en production au démarrage du 23/10/2026 à 22:28:44 UTC : user=vigifi_login, role_applicatif=vigifi_app, rls_contournee=false, audit_modifiable=false, exigence=strict.

• Des tests d'intégration vérifient que la RLS s'applique sous le rôle applicatif [internal/platform/db/rls_integration_test.go:28,127, internal/platform/db/connect_integration_test.go:21].

2.2 Contrôle d'accès des utilisateurs du Client (console et API).

• Rôles : owner, admin, viewer, et reception limité aux sites affectés à l'utilisateur. Les opérations d'écriture sont réservées à owner et admin [internal/platform/httpx/auth.go:65-74, internal/platform/httpx/reception.go:18, docs/rbac-reception-affectations.md]. Le retrait d'un droit prend effet à la requête suivante, sans attendre l'expiration de la session.

• Mots de passe : hachés avec argon2id (t=3, m=64 Mio, p=2, sel aléatoire de 16 octets) et comparés en temps constant [internal/platform/crypto/password.go:13-71].

• Protection contre la force brute : le compte est verrouillé 15 minutes après 5 échecs consécutifs [internal/platform/config/config.go:388-389, internal/tenant/service.go:173-182]. Le débit est limité par adresse IP sur les routes publiques et d'authentification [internal/platform/httpx/server.go:62].

• Second facteur : TOTP, avec un secret chiffré au repos et des codes de secours à usage unique dont la consommation est atomique [internal/tenant/service.go:289-477]. Le second facteur est obligatoire pour les rôles d'administration connectés par mot de passe. Pour les connexions par authentification unique, il relève du fournisseur d'identité du Client [internal/tenant/service.go:192-228, docs/totp-obligatoire.md]. Le Client peut aussi utiliser l'authentification unique Microsoft Entra ID.

• Sessions : jeton opaque aléatoire de 256 bits, dont seule l'empreinte est stockée en base [internal/tenant/service.go:856-871]. Il est transmis dans un cookie HttpOnly, Secure en production, SameSite=Lax [internal/platform/httpx/cookies.go:16-27]. La session expire après 12 heures ; une session en attente du second facteur expire après 5 minutes [config.go:396-397]. Le jeton est remplacé à la validation du TOTP, contre la fixation de session [service.go:456-466]. L'utilisateur peut révoquer ses sessions individuellement ou toutes ses autres sessions, avec effet immédiat [internal/tenant/sessions.go:43-69].

• Jetons d'API : jetons opaques à portées (scopes) granulaires, stockés sous forme d'empreinte et affichés une seule fois à la création, avec expiration et rotation [docs/architecture.md §10, internal/tenant/service.go:557-830].

2.3 Sécurité applicative. Les réponses HTTP portent des en-têtes de sécurité (Content-Security-Policy: default-src 'none', X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: no-referrer, et Strict-Transport-Security en production) [internal/platform/httpx/middleware.go:44-51]. La taille des corps de requête et les délais serveur sont bornés [docs/architecture.md §9].

3. Intégrité

3.1 Journaux de connexion scellés. Chaque connexion d'un visiteur crée une entrée de journal numérotée par Client. Cette entrée contient l'empreinte SHA-256 de ses champs scellés et de l'empreinte de l'entrée précédente : c'est le chaînage cryptographique. Les champs scellés sont le numéro, le Client, le site, la méthode, l'empreinte d'identité, les adresses MAC et IP, les horodatages et la version des conditions acceptées [internal/compliance/chain.go:19-47, internal/compliance/service.go:124-205]. Les ajouts sont sérialisés par Client [service.go:159-162]. Une vérification recalcule la chaîne et signale la première rupture [service.go:274-311, route GET /api/v1/compliance/integrity].

Portée : la chaîne prouve qu'aucune entrée conservée n'a été modifiée. Elle ne prouve pas qu'aucune entrée récente n'a été perdue, par exemple après une restauration tronquée [docs/resilience.md:83-85].

3.2 Export signé. Les journaux peuvent être exportés dans une archive qui contient les données, la chaîne, un manifeste (bornes de la chaîne, empreintes SHA-256), une signature Ed25519 détachée, la clé publique et un script de vérification hors ligne. Ce script n'utilise qu'OpenSSL et ne dépend d'aucun service de l'Éditeur [internal/compliance/export.go:73-160, internal/compliance/verify.sh, docs/architecture.md §7, ADR-0007]. Chaque export est tracé dans le journal d'audit, avec l'empreinte de l'archive et sans donnée personnelle.

3.3 Purges tracées. Chaque purge de rétention est enregistrée dans le journal d'audit, dans la même transaction que la suppression. L'enregistrement donne les bornes du segment retiré et la dernière empreinte supprimée. Si la trace ne peut pas être écrite, rien n'est supprimé [internal/compliance/service.go:416-489].

4. Disponibilité et résilience

• Le service est conçu pour fonctionner en plusieurs instances, coordonnées uniquement par PostgreSQL : file de travaux avec réservation exclusive, tâches planifiées protégées par un verrou consultatif, limitation de débit partagée. Ces invariants sont couverts par des tests automatisés [ADR-0006, docs/resilience.md].

• Constaté en production (23/10/2026) : le service fonctionne sur une instance applicative et une instance de base de données, dans une même région (Railway europe-west4-drams3a, Amsterdam, Pays-Bas), sans réplication ni bascule automatique. Une panne de l'une ou de l'autre interrompt le service jusqu'à son rétablissement. La base n'est pas un service PostgreSQL managé : c'est un conteneur postgres:16-alpine sur un volume persistant. Aucun niveau de disponibilité n'est garanti (CGV art. 5.1).

• Supervision : métriques au format Prometheus exposées par le service, et alertes de l'opérateur par courriel [ADR-0006, docs/monitoring/]. Il n'y a pas de télémétrie vers un tiers.

5. Sauvegarde et restauration

• Constaté : la base de production réside sur un volume Railway unique de 5 Go, dans la région europe-west4-drams3a. Aucune sauvegarde automatisée ni restauration à un instant donné (PITR) n'a été vérifiée. Aucun exercice de restauration n'a été réalisé sur un environnement de production ou de pré-production.

• Le comportement attendu d'une restauration (reprise des travaux en attente, revérification de la chaîne, opposabilité de l'export signé) est testé sur une base de test [internal/compliance/restore_drill_integration_test.go, docs/resilience.md:71-85].

• À ce jour, l'Éditeur ne s'engage donc sur aucune fréquence de sauvegarde, durée de conservation des sauvegardes, objectif de point de reprise (RPO) ni délai de restauration (RTO). Voir Écarts connus, E1.

6. Journalisation et audit

• Actions d'administration : les actions sensibles sont enregistrées dans un journal d'audit dans la même transaction que l'action. Si l'enregistrement échoue, l'action est annulée [ADR-0007, internal/audit]. Le journal est en ajout seul pour le rôle applicatif, sans droit de modification ni de suppression ; ce point est vérifié au démarrage [migrations/00092_audit_append_only.sql]. Le journal d'audit n'est pas scellé cryptographiquement : le propriétaire de la base garde tous les droits sur lui [00092_audit_append_only.sql, commentaire « portée honnête »].

• Contenu : l'auteur (utilisateur, jeton d'API ou système), l'action, la cible et des métadonnées. L'effacement d'une identité n'enregistre que son empreinte, jamais sa valeur [internal/compliance/service.go:408-411].

• Relais : le Client peut faire relayer son journal d'audit vers son propre SIEM par syslog [internal/siem/syslog.go].

• Journaux techniques : journaux structurés du service, conservés par l'hébergeur (Railway). Les journaux HTTP de l'hébergeur contiennent les adresses IP des clients HTTP. Leur durée de conservation chez l'hébergeur n'est pas vérifiée.

7. Sécurité des transmissions

• Le navigateur ne communique qu'avec le frontal (Vercel), en HTTPS. Le frontal appelle l'API côté serveur, en HTTPS. HSTS est actif en production [docs/deploy.md §« Architecture de déploiement », middleware.go:51].

• Les fonctions du frontal sont épinglées dans la région cdg1 (Paris) [frontend/vercel.json], afin que les données des visiteurs du portail ne transitent pas par la région par défaut, située aux États-Unis.

• En 802.1X, les échanges RADIUS sont transportés en RadSec (TLS mutuel) [docs/radsec.md]. Le 802.1X n'est pas activé en production au 23/10/2026 : RADSEC_ENABLED est absent, et sa valeur par défaut est false.

• Le chiffrement TLS vers le relais SMTP n'est pas vérifié.

8. Localisation de l'hébergement

Les composants qui traitent des données du Client sont hébergés dans l'Union européenne : service applicatif et base de données sur Railway (europe-west4-drams3a, Amsterdam, Pays-Bas), fonctions du frontal sur Vercel (cdg1, Paris) [docs/deploy.md §« Engagement d'hébergement », constaté le 23/10/2026]. Cet engagement porte sur la localisation. Railway et Vercel sont des sociétés de droit américain. La liste des sous-traitants ultérieurs figure à l'Annexe IV.

Note de rédaction : l'Annexe IV doit au minimum citer Railway, Vercel, le relais SMTP (fournisseur non identifié dans le dépôt) et Microsoft (Entra ID, lorsque le Client l'utilise). docs/deploy.md décrit encore Azure comme cible finale ; un changement d'hébergeur modifiera l'Annexe IV.

9. Gestion des clés et des secrets

• Génération et stockage : les secrets sont générés hors du dépôt et injectés par variables d'environnement. Aucun secret n'est écrit dans le code. En production, le service vérifie la présence et la taille des clés au démarrage [internal/platform/config/config.go:352-444].

• Clé de signature des exports (EXPORT_SIGNING_KEY) : chaque export embarque sa clé publique. Les exports passés restent donc vérifiables après une rotation [docs/architecture.md §9.1].

• Clé maître de chiffrement (DATA_ENCRYPTION_KEY) : le chiffré ne porte pas d'identifiant de version de clé, et l'ancienne et la nouvelle clé ne peuvent pas coexister. Une rotation suppose donc :

  1. une fenêtre de maintenance ;

  2. le déchiffrement puis le rechiffrement de toutes les valeurs chiffrées, Client par Client ;

  3. la perte des empreintes HMAC calculées avec cette clé ou avec une clé qui en est dérivée : appareils reconnus, secrets de reconnexion, statistiques d'appareil 802.1X, index de recherche des personnes enrôlées [internal/portal/returning.go:29, reconnect.go:100, internal/authfeed/fingerprint.go:39, internal/enroll/service.go:211, internal/pki/enroll.go:252]. Ces empreintes ne se rechiffrent pas, elles sont à reconstituer ou à abandonner.

  La perte de cette clé rend les données chiffrées définitivement illisibles [docs/architecture.md §9.1]. La clé de chiffrement ne peut pas, à ce jour, être remplacée sans interruption de service. Un mécanisme de rotation (enveloppe versionnée, rechiffrement en ligne) est prévu [ADR-0018, ELF-157]. Une rotation reprotège les données ; elle ne suffit pas si la clé a été exposée avec une copie de la base (voir §13).

• Sauvegarde des clés : la procédure cible (Azure Key Vault) est décrite [docs/architecture.md §9.1]. En production, les clés sont des variables Railway. Leur sauvegarde hors de Railway n'est pas vérifiée.

10. Cloisonnement des environnements

• Les environnements de développement et de test n'utilisent que des données fictives. L'environnement de pré-production (staging) est un projet Railway distinct de la production, dont les secrets sont générés et non copiés de la production. Il ne contient aucune donnée réelle de visiteurs ni de journaux [docs/staging.md §2-3, docs/deploy.md:19-20].

• L'environnement de staging décrit par docs/staging.md n'est pas encore opérationnel [docs/resilience.md:18-22].

11. Durées de conservation et minimisation

12. Assistance au Client pour les droits des personnes concernées

• Effacement (art. 17) : pendant les 12 mois de conservation légale, l'effacement prend la forme d'une pseudonymisation, pas d'une suppression [ADR-0007, ADR-0014]. Le Client la déclenche par la console ou par l'API (POST /api/v1/compliance/pseudonymize, rôles owner/admin) [internal/compliance/http.go:46, :379]. Dans une seule transaction [internal/compliance/service.go:374-414], l'opération :

  • efface l'identité en clair de toutes les entrées de journal de la personne ;

  • supprime les réponses aux champs personnalisés de ces connexions ;

  • supprime les appareils reconnus et leurs secrets de reconnexion ;

  • efface l'état d'authentification de ces appareils ;

  • consigne l'opération dans le journal d'audit sous la seule empreinte de l'identité.

  Restent jusqu'à la fin des 12 mois : l'empreinte non clée de l'identité, les adresses MAC et IP et les horodatages, exigés par l'article L34-1 du CPCE et scellés dans la chaîne. Ils sont ensuite supprimés par la purge de rétention.

• Personnes enrôlées en 802.1X : leur pseudonymisation retire toute identité. L'invariant est garanti par une contrainte en base [migrations/00106_enrollment_core.sql, contrainte enrollment_persons_pseudonymized_clean].

• Accès et portabilité (art. 15 et 20) : le Client peut exporter les journaux (CSV ou JSON, export signé) et les réponses aux champs personnalisés (GET /sites/{id}/portal-form-answers) [internal/compliance/http.go:30-34, docs/architecture.md §formulaire]. Il n'existe pas de recherche par personne : le Client filtre lui-même l'export.

• L'Éditeur transmet au Client, sans y répondre lui-même, toute demande qu'il reçoit directement d'une personne concernée (clause 8 des clauses types).

13. Notification des violations de données

• L'Éditeur notifie au Client toute violation de données personnelles qui le concerne dans un délai maximal de 48 heures après en avoir pris connaissance. [Valeur proposée, à valider par la direction et par l'avocat.] Ce délai laisse au Client une marge sur son propre délai de 72 heures envers l'autorité de contrôle (art. 33 RGPD).

• La notification contient au minimum les éléments de l'article 33, paragraphe 3, du RGPD, éventuellement transmis en plusieurs fois.

• L'Éditeur applique une procédure écrite de gestion des violations de données : détection, confinement, qualification, notification au Client et registre. La procédure fait l'objet d'un exercice annuel ; le premier a lieu avant le premier contrat payant [docs/violation-donnees.md, en vigueur depuis le 24/10/2026].

• Si la clé maître de chiffrement est exposée en même temps qu'une copie de la base, rechiffrer ne suffit pas : les secrets techniques concernés (autorités de certification du Client, secrets TOTP, secrets RADIUS…) doivent être renouvelés. Certains ne peuvent l'être que par le Client, chez son propre fournisseur. La notification indique au Client lesquels [docs/violation-donnees.md §4].

• Limite : la procédure couvre les obligations du RGPD. Elle ne couvre pas les délais de notification d'incident propres à la directive NIS2 (alerte précoce sous 24 heures) auxquels certains Clients sont soumis ; une notification sous 48 heures ne leur permet pas de les tenir [docs/violation-donnees.md §10].

  Note de rédaction : puce « Limite » à revoir à la livraison d'ELF-161 (notification adaptée aux Clients soumis à NIS2).

• Le registre d'incidents de la console [migrations/00011_incidents.sql] est un outil mis à la disposition du Client pour ses propres incidents. Ce n'est pas le registre des violations de l'Éditeur.

14. Gestion des vulnérabilités

• Chaque modification du code passe par une revue et par l'intégration continue avant fusion : formatage, cohérence du code SQL généré, analyse statique golangci-lint (configuration par défaut), tests unitaires et d'intégration [.github/workflows/ci.yml].

• Les modifications qui touchent l'isolation entre Clients, la cryptographie, la PKI ou l'authentification font l'objet d'une revue de sécurité dédiée (rôle Secu).

• Aucune analyse automatique des dépendances vulnérables, aucun scan de secrets et aucun test d'intrusion externe n'ont été réalisés à ce jour (voir E4).

15. Sécurité des postes et des accès internes

• L'accès aux environnements de production (Railway, Vercel, GitHub) est réservé au personnel de l'Éditeur. Les déploiements de production observés sont déclenchés par un compte nominatif unique.

• L'authentification multifacteur sur ces comptes, la politique de sécurité des postes de travail et la revue périodique des accès ne sont ni documentées ni vérifiées (voir E10).

16. Fin du contrat : restitution et suppression

• Restitution en cours de contrat : à tout moment, le Client peut exporter ses journaux (export signé), les réponses aux champs personnalisés et sa configuration par l'API [§12].

• Demande de clôture : un administrateur owner du Client demande la clôture de son compte par l'API (POST /api/v1/tenant/closure). La demande exige une session de console (un jeton d'API ne suffit pas), le mot de passe du demandeur, son code TOTP s'il est actif, et la saisie de l'identifiant court (slug) du Client [internal/tenant/closure_http.go:39-52,177-194]. À la fin du contrat, si le Client ne l'a pas demandée, l'Éditeur ouvre la même clôture par un outil d'exploitation, sur une référence obligatoire (contrat ou ticket), inscrite au journal d'audit du Client [internal/tenant/closure.go:193-199, docs/cloture-tenant.md §2]. La demande est refusée tant que le Client a des sous-tenants (un MSP les clôt d'abord, ou les détache vers leur client) [ADR-0019 §2], ou tant qu'un de ses administrateurs a encore accès à un autre compte du Service, par une appartenance déléguée ou un jeton d'API actif [closure.go:228].

• Pendant les 30 jours qui suivent la demande [internal/tenant/closure.go:29-30] :

  • le service s'arrête : le portail, le 802.1X (RadSec, EST, SCEP), les webhooks et le relais SIEM refusent le Client. Aucune nouvelle donnée d'invité, d'appareil ou de personne enrôlée n'entre ; seules s'inscrivent les traces de l'activité des administrateurs (connexions, journal d'audit, avis par courriel). L'API passe en lecture seule, sauf l'export de clôture, l'annulation, la pseudonymisation (identités du portail et personnes enrôlées) et ce qui permet de se connecter et de protéger les comptes : connexion, y compris par SSO, mot de passe, TOTP, révocation de sessions et de jetons d'API, changement de compte pour un MSP [internal/platform/httpx/closing.go:9-42] ;

  • un export de clôture signé est construit. Il contient : les journaux de connexion complets et leur chaîne, les réponses aux champs personnalisés, le journal d'audit, la configuration sans les secrets, les personnes enrôlées en 802.1X, ainsi que les comptes administrateurs, les bons d'accès et les appareils autorisés en MAB. Les secrets techniques n'y figurent pas. Les données de fonctionnement (sessions 802.1X, demandes de parrainage, appareils en attente d'autorisation, statistiques par appareil) n'y figurent pas non plus et ne sont pas restituées : elles sont supprimées à l'échéance avec le reste [ADR-0019, amendement du 24/10/2026]. Jusqu'à l'échéance, l'API en affiche en lecture les plus récentes, sans en garantir l'intégralité. Les accès octroyés par parrainage figurent, eux, dans les journaux de connexion. Il se vérifie hors ligne, comme l'export du §3.2. Il est stocké chiffré en base, lié au Client (§1.1) [internal/compliance/closure_export.go:27-35] ;

  • son téléchargement est réservé à un owner ré-authentifié (mot de passe, et TOTP s'il est actif). Chaque téléchargement est inscrit au journal d'audit [closure_http.go:51-56,143-155] ;

  • un courriel est adressé à tous les owner du Client à la demande, à chaque téléchargement de l'export, et 7 jours avant la suppression [ADR-0019 §2, closure.go:31-32] ;

  • la pseudonymisation d'une identité (§12) reste possible. Elle supprime l'export de clôture déjà construit, qui contenait l'identité en clair, et l'export est reconstruit sans elle. Une archive que le Client a déjà téléchargée n'est pas modifiée : il revient au Client d'y appliquer l'effacement [docs/cloture-tenant.md §1] ;

  • un owner peut annuler la clôture jusqu'à l'échéance. Le service reprend aussitôt et l'export déjà construit est supprimé.

• Suppression : à l'échéance, toutes les données du Client sont supprimées en une transaction, par la suppression en cascade du Client (REFERENCES tenants(id) ON DELETE CASCADE), journal d'audit compris [migrations/00010_audit.sql:7]. La transaction est annulée si une ligne du Client subsiste après la cascade [closure.go:518]. Elle inscrit, dans la même transaction, une preuve de suppression sans donnée personnelle : identifiant du Client, dates de la demande et de la suppression, auteur de la demande (le Client ou l'Éditeur, sans identifiant de personne), empreinte du manifeste de l'export de clôture et nombre de lignes supprimées par table [migrations/00118_cloture_tenant.sql, ADR-0019 §4]. La suppression est suspendue, et l'exploitation de l'Éditeur alertée, tant que l'export de clôture n'a pas été construit, ou qu'un administrateur du Client a encore accès à un autre compte du Service : supprimer sans avoir restitué détruirait la preuve que le Client doit conserver [docs/cloture-tenant.md §3, closure.go:486].

• Certificat de suppression : sur demande du Client, l'Éditeur lui remet sous [15 jours] un certificat établi à partir de la preuve de suppression. Le Client peut comparer l'empreinte du manifeste qu'il contient à celle de l'archive qu'il a téléchargée. L'empreinte est celle de la dernière archive construite. Une archive téléchargée avant une pseudonymisation ne lui correspond pas [docs/cloture-tenant.md §4].

• Conservé après la suppression, pour le compte de l'Éditeur : la preuve de suppression ci-dessus, et les preuves d'acceptation du présent accord et des CGV (notamment le nom du Client, l'identifiant, l'adresse e-mail et la méthode d'authentification de l'administrateur qui les a acceptés, son adresse IP et son navigateur), pendant 5 ans après la suppression, au titre de la preuve du contrat [ADR-0017 §8, docs/cloture-tenant.md §4 bis]. Ce ne sont pas des données traitées pour le compte du Client.

  Note de rédaction : clôture constatée en production le 24/10/2026 à 22:03 UTC (déploiement Railway 834cb2c2, commit 03e8026, migration 118 appliquée selon les journaux de démarrage ; sans authentification, GET /api/v1/tenant/closure répond 401 et non 404). Après la mise en production de l'écran de clôture (ELF-155), écrire « par la console ou par l'API ». L'envoi effectif des courriels aux owner n'est pas observé en production : relais SMTP de production non identifié (annexe IV), à constater avant le passage en version finale. Le délai de 30 jours est une constante du code (ClosureGraceDays), alignée sur l'art. 8.2 des CGV : le modifier demande une nouvelle version du code, pas seulement du texte.

• Articulation avec la LCEN : les journaux de connexion de moins de 12 mois sont soumis à une obligation légale de conservation qui pèse sur le Client. Option retenue par défaut : (A) restitution par export signé, puis suppression totale. C'est celle que met en œuvre la clôture décrite ci-dessus. L'obligation de conservation pèse sur le Client, et l'export signé se vérifie sans l'Éditeur. L'option (B), où l'Éditeur conserverait les journaux jusqu'à leur échéance, n'est pas construite. [Point à confirmer par l'avocat.]

• Les sauvegardes éventuelles (voir §5) contiennent des données supprimées jusqu'à leur propre expiration. Cette durée n'est pas définie à ce jour. Si une sauvegarde antérieure à une suppression est restaurée, la suppression est rejouée à partir des preuves de suppression avant la reprise du service [docs/cloture-tenant.md §5].

ANNEXE IV — Liste de sous-traitants ultérieurs

Source : document annexe-iv partie A (SRE, ELF-135). La partie B (preuves) reste interne. Non signable tant que le relais SMTP de production n'est pas identifié.

Mode d'autorisation retenu (clause 7.7)

Option 2 — autorisation écrite générale, sur la base de la liste ci-dessous. Le sous-traitant informe spécifiquement par écrit le responsable du traitement de tout projet d'ajout ou de remplacement de sous-traitant ultérieur au moins trente (30) jours calendaires à l'avance, ce qui laisse au responsable du traitement le temps d'émettre des objections avant le recrutement. L'information est envoyée aux administrateurs (rôle owner) du tenant à l'adresse e-mail de leur compte.

Sous-traitants ultérieurs autorisés (état au 24/10/2026)

1. Railway Corporation

• Adresse : 548 Market St PMB 68956, San Francisco, California 94104, États-Unis.

• Contact : [À COMPLÉTER — aucun contact nominatif n'est publié sur les pages consultées ; point d'entrée public : https://trust.railway.com].

• Description du traitement : hébergement de l'application du Service (serveur d'API et de portail) et de la base de données PostgreSQL. Y sont stockés : comptes des administrateurs (e-mail, empreinte du mot de passe, secret TOTP chiffré), journaux de connexion des visiteurs du WiFi invité (adresse MAC et adresse IP de l'appareil, identité déclarée chiffrée au repos, horodatages, méthode d'accès), réponses aux champs personnalisés du portail (chiffrées), journaux d'audit, configuration des sites et contrôleurs. Le traitement confié à Railway se limite à l'hébergement et à l'exploitation de l'infrastructure.

• Lieu d'exécution et de stockage : région europe-west4 (Pays-Bas) pour le service applicatif et pour le volume de la base de données. Une seule réplique, une seule région.

• Garanties de transfert : Railway Corporation est une société de droit américain. L'accès à distance depuis les États-Unis (exploitation, support) n'est pas exclu par les pages consultées. Cadre contractuel : DPA de Railway, qui prévoit le Data Privacy Framework « le cas échéant » et les clauses contractuelles types (décision 2021/914) pour les transferts hors EEE. Certification DPF de Railway non vérifiée au registre officiel. Module des clauses types applicable non précisé sur la page consultée.

• Sous-traitants de rang 2 : ceux publiés par Railway sur https://trust.railway.com/item/subprocessors (au 24/10/2026 : Fathom Analytics, Cloudflare, Causal, Customer.io, Stripe ; infrastructure sur Google Cloud Platform). Railway s'engage à informer ses clients au moins 10 jours avant d'en activer un nouveau.

2. Vercel Inc.

• Adresse : 440 N Barranca Ave #4133, Covina, California 91723, États-Unis.

• Contact : [À COMPLÉTER — point d'entrée public : https://security.vercel.com].

• Description du traitement : exécution de l'interface web (console d'administration et portail captif des visiteurs). Le serveur de Vercel reçoit les requêtes du navigateur et les relaie à l'API hébergée chez Railway. Transitent donc par Vercel : l'adresse IP du visiteur, les paramètres de redirection du contrôleur WiFi (dont l'adresse MAC de l'appareil et l'URL de continuation), les formulaires saisis par le visiteur (e-mail, nom, réponses aux champs personnalisés, code d'accès, numéro de téléphone si la méthode SMS est activée), les cookies de session des administrateurs et les en-têtes HTTP. Vercel ne conserve pas ces données à titre de base de données applicative ; ses journaux de plateforme peuvent en contenir des traces (durée et contenu non vérifiés).

• Lieu d'exécution : fonctions serveur épinglées sur cdg1 (Paris, France) (frontend/vercel.json), confirmé sur la production le 24/10/2026. Réserve : le filtre d'entrée du portail et de la console (« middleware ») s'exécute sur le réseau périphérique de Vercel, au point de présence le plus proche du visiteur, et n'est pas épinglé sur Paris. Lieu de conservation des journaux de plateforme de Vercel : non vérifié.

• Garanties de transfert : Vercel Inc. est une société de droit américain, et son DPA indique que ses installations principales de traitement sont aux États-Unis. Cadre contractuel : DPA de Vercel (dernière mise à jour affichée : 17/03/2026, entrée en vigueur : 31/03/2026), qui incorpore les clauses contractuelles types 2021 (modules 1, 2 et 3). Le centre de confiance de Vercel affiche les certifications EU-US DPF, Swiss-US DPF et l'extension britannique ; leur inscription au registre officiel n'a pas été vérifiée.

• Sous-traitants de rang 2 : ceux publiés par Vercel sur https://security.vercel.com (au 24/10/2026 : Honeycomb, Datadog, Microsoft, Google, Amazon Web Services). Préavis de Vercel pour un ajout : 5 jours calendaires.

3. Relais SMTP (envoi des e-mails transactionnels)

• Nom, adresse, contact : [À COMPLÉTER PAR elfayafi — fournisseur du relais SMTP de production non identifié ; voir B.6].

• Description du traitement : acheminement des e-mails envoyés par l'Éditeur : invitations et réinitialisations de mot de passe des administrateurs, alertes d'exploitation, rapports d'usage hebdomadaires (optionnels), alertes de dérive de configuration, envoi de codes d'accès WiFi à une adresse choisie par l'administrateur, demandes d'approbation adressées à un parrain. Données : adresse du destinataire, objet et corps du message (le corps peut contenir des codes d'accès WiFi et le nom d'un visiteur).

• Lieu d'exécution et garanties de transfert : [À COMPLÉTER — non vérifié].

Transferts de données à caractère personnel hors de l'Union européenne

À l'état actuel, deux des sous-traitants ultérieurs (Railway Corporation et Vercel Inc.) sont des sociétés de droit américain. Le stockage de la base et l'exécution des fonctions serveur se font dans l'Union (Pays-Bas, France), mais un accès depuis les États-Unis par ces sociétés, pour l'exploitation ou le support, ne peut pas être exclu. Les garanties sont celles décrites ci-dessus (clauses contractuelles types ; DPF indiqué par les fournisseurs, non vérifié au registre officiel). Aucune autre garantie technique de l'Éditeur ne s'oppose à une demande d'accès émanant d'une autorité des États-Unis auprès de ces sociétés : l'identité des visiteurs est chiffrée au repos, mais la clé de chiffrement est conservée dans la configuration du même hébergeur.

La promesse de l'Éditeur porte sur la localisation (hébergement dans l'Union européenne), pas sur une protection contre le droit des États-Unis.

Services que le client utilise lui-même (hors liste)

Ne sont pas des sous-traitants ultérieurs de l'Éditeur, car le client les choisit, les configure avec ses propres identifiants et reste leur donneur d'ordre : Microsoft Entra ID, Microsoft Graph et Intune (configuration des appareils, enrôlement), l'API cloud du constructeur du contrôleur WiFi (Meraki), les points de livraison de webhooks, le serveur SIEM (syslog) et les fournisseurs d'identité sociale du portail. L'Éditeur ne leur transmet que ce que le client a configuré. [À faire confirmer par l'avocat : cette qualification.]

Changements prévus (non applicables à ce jour)

Une migration de l'hébergement vers Microsoft Azure, région France Central est prévue (docs/deploy.md:3-5, 191-197). Elle n'est pas en place et n'est pas autorisée par la présente annexe. Elle sera notifiée selon la clause 7.7 (préavis de trente jours) avant toute bascule de données réelles.