Registre des activités de traitement (Art. 30 RGPD)

Ce document est publié en plusieurs langues. En cas de divergence entre les versions linguistiques, la version polonaise fait foi.

Version 1.2 · Dernière mise à jour : 29 octobre 2026

1. Comment lire ce registre

Ceci est le registre des activités de traitement au titre de l’Art. 30 RGPD pour formexposed. Ce n’est ni une politique de confidentialité ni un document marketing. Son rôle est de montrer à une autorité de contrôle, à un Client qui nous audite en tant que sous-traitant, ou à la prochaine personne qui devra répondre à une question, ce qui est réellement traité, où c’est conservé, qui le reçoit et combien de temps cela reste. Nous le publions parce qu’un service qui vérifie et surveille des formulaires doit lui-même pouvoir être vérifié.

Trois règles ont guidé sa rédaction.

1. Mesuré, pas voulu. Une affirmation sur les champs de données, les durées de conservation, les destinataires ou les garanties n’apparaît que lorsque le code du programme, le schéma de la base de données ou une mesure l’étaye. Ce qui est prévu est qualifié de « prévu ». Ce qui est désactivé par défaut est qualifié de « désactivé par défaut ». Lorsque nous ne pouvons pas prouver quelque chose, nous le disons.
2. La conservation est indiquée deux fois. Une fois pour chaque activité de traitement et une fois à la section 6 pour la vue d’ensemble : quel traitement nocturne supprime quelles données, et quelles données il n’atteint pas. Un registre qui revendique une durée de conservation ne s’appliquant qu’à une partie des données est pire qu’un registre qui nomme le point en suspens.
3. Les points en suspens figurent dans le texte, pas dans une note de bas de page. La section 8.1 énumère les mesures qui n’ont pas encore été mises en œuvre, la section 10 les points en suspens avec les mesures prévues. Un registre est un outil de travail, pas un certificat.

Des champs de données plutôt que des noms de tables. Pour chaque activité de traitement, nous énumérons les données enregistrées sous forme de champs en langage clair. Le nom de la table de la base de données suit entre parenthèses afin qu’un auditeur puisse trouver l’emplacement, par exemple « tentatives de connexion (login_attempts) ». Les listes de champs ont été déduites du schéma de la base de données, et non de mémoire.

Les durées de conservation sous forme de variables. Lorsqu’une durée de conservation peut être définie dans l’espace d’administration, elle apparaît ici exactement telle que le traitement nocturne la lit : le nombre que vous voyez provient du même paramètre que celui qui régit la suppression. Les durées de conservation fixées dans le programme sont indiquées sous forme de nombres.

Base de mesure. Le schéma, le code et les paramètres ont été mesurés le 11 October 2026 sur le système de développement, qui correspond au système de production en termes de code et de schéma. Nous n’indiquons pas de nombre de lignes issu du système de développement ; elles contiennent des données de test et ne disent rien du fonctionnement réel.

Délibérément omis. Ce registre ne mentionne ni noms d’hôtes, ni adresses réseau internes, ni ports, ni noms d’utilisateur, ni versions de logiciels de nos serveurs. De tels détails aident un attaquant et aucune personne concernée. Pour la même raison, nous ne décrivons qu’en termes généraux les points en suspens relatifs à la sécurisation de nos propres serveurs (section 8.1) : nous nommons le risque, pas le chemin qui y mène. Nous communiquons les détails à une autorité de contrôle sur demande.

Nature juridique. Ce registre est la documentation que nous tenons au titre de l’Art. 30 RGPD à l’intention de l’autorité de contrôle ; il est publié volontairement. Il ne fait partie d’aucun contrat et ne constitue aucune déclaration, garantie ni convention de qualité à l’égard des Clients ou de tiers. Ce que nous devons aux Clients est régi par les Conditions d’utilisation, le Contrat de sous-traitance et ses annexes ; s’agissant de ces obligations, ils prévalent sur ce registre. Le registre décrit la situation à la date de la présente version. Les qualifications telles que « point en suspens » ou « appréciation » reflètent notre propre point de vue et ne préjugent d’aucune évaluation juridique par une autorité de contrôle ou une juridiction ; les mesures qualifiées de « prévues » sont des intentions sans date d’engagement.

2. L’entité juridique et pourquoi ce registre comporte deux moitiés

Champ	Mention
Entité juridique	LW IT Solutions Company Lukas Wójcik, entreprise individuelle immatriculée au registre polonais des entreprises (CEIDG) ; propriétaire Lukas Wójcik
Adresse	al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Pologne
Identifiants fiscaux	NIP 7252266190, numéro de TVA PL7252266190
Contact	contact@lukaswojcik.com ; la fenêtre d’assistance (point d’interrogation dans la navigation) ; la page de contact
Service	formexposed : vérification, surveillance et sécurisation des formulaires de contact sur les sites web (application sur formexposed.com, page d’accueil sur form.exposed)
Représentant au titre de l’Art. 27 RGPD	Sans objet. L’entité juridique est établie dans l’Union (Pologne).
Délégué à la protection des données	Non désigné. L’appréciation au titre de l’Art. 37 figure à la section 9.
Autorité de contrôle compétente	Prezes Urzędu Ochrony Danych Osobowych (UODO, l’autorité polonaise de protection des données), ul. Moniuszki 1A, 00-014 Warszawa
Hébergement	Nos propres serveurs en Pologne : un serveur web avec l’application et la base de données, et un serveur d’analyse avec un modèle de langage local sur le même réseau interne. Aucun centre de données ni fournisseur de cloud tiers.

formexposed joue des rôles différents à l’égard de différents groupes de personnes. Les confondre produit un registre qui n’est juste pour aucun d’entre eux.

• Responsable du traitement (partie B, Art. 30(1)). Nous sommes nous-mêmes responsables du traitement pour les données de nos propres Clients et des membres de leurs équipes (compte, connexion, facturation, assistance, journaux), pour les visiteurs de notre propre site web, pour les vérifications sans compte (vérification gratuite, outil d’en-têtes, étude, vérification de prospects) et pour la prévention des abus.
• Sous-traitant (partie A, Art. 30(2)). Pour les données à caractère personnel de tiers qu’un Client introduit dans le service ou qui sont générées lorsque nous fournissons un service au Client, nous agissons pour le compte du Client : copies d’e-mails de formulaire réels dans le contrôle de livraison, abonnés au portail client du Client, destinataires des alertes du Client, personnes visibles de manière fortuite sur les pages vérifiées du Client, identifiants du compte de test du Client et code de formulaire que le Client colle. Le fondement est le Contrat de sous-traitance, conclu avec chaque Client lors de l’inscription.
• Uniquement du côté du Client. Certaines fonctions du plugin WordPress et de l’extension TYPO3 traitent des données exclusivement sur le site web du Client, sans que ces données ne nous parviennent jamais (quarantaine, filet de sécurité, énigme arithmétique, paramètres de conservation, compteurs locaux, enregistreur). Il ne s’agit pas de traitements effectués par nous ; ils n’apparaissent donc dans aucune des deux parties. Nous les décrivons néanmoins à la fin de la partie A afin que la limite soit visible.

La séparation est intégrée dans le code, et pas seulement dans le texte : d’un e-mail de formulaire réel, le contrôle de livraison n’écrit dans la base de données que l’heure, le rattachement et le résultat d’authentification ; les captures d’écran des vérifications par navigateur masquent les champs de saisie ; les identifiants du compte de test sont chiffrés de telle sorte que le serveur web ne peut plus les lire. Les détails figurent dans les entrées.

Les sections 6 à 11 s’appliquent aux deux moitiés : conservation, décisions automatisées, mesures techniques et organisationnelles, délégué à la protection des données, points en suspens et tenue de ce registre.

Périmètre. Ce document est la partie du registre qui concerne le service formexposed. Les traitements effectués par la même entité juridique pour d’autres services sont consignés dans leurs propres registres ; la comptabilité générale et la gestion de l’entreprise en dehors du service ne sont pas couvertes par cette partie.

3. Partie A – Art. 30(2) : traitements pour le compte des Clients

A.0 Parties concernées

Champ	Mention
Sous-traitant	LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Pologne ; contact@lukaswojcik.com
Responsables du traitement	Les Clients de formexposed : entreprises et agences qui détiennent des domaines dans leur compte et utilisent des fonctions dans lesquelles des données de tiers sont générées. Pour les agences, le propre client de l’agence peut en outre être le responsable du traitement ; l’agence agit alors en tant que sous-traitant à l’égard de ce client et nous en tant que sous-traitant ultérieur.
Liste des responsables du traitement	Partie de ce registre, tenue sous forme électronique (Art. 30(3) RGPD) dans le système du service et non reproduite dans la présente version publique, car elle contient des données à caractère personnel des Clients et serait obsolète à chaque nouveau Client : le propriétaire de chaque espace de travail avec son nom, son adresse e-mail et son entreprise issus du compte client (adresse et numéro de TVA uniquement chez Stripe) (users, workspaces, workspace_users), ainsi que les domaines de l’espace de travail (domains). Nous la fournissons sur demande à une autorité de contrôle sous forme d’extrait.
Représentants et délégués à la protection des données des responsables du traitement	Il n’existe pas de champ dédié à cet effet dans le système. Si un Client a désigné un représentant au titre de l’Art. 27 RGPD ou un délégué à la protection des données, il peut nous en informer ; nous conservons cette information avec la liste des responsables du traitement.
Représentant du sous-traitant	Sans objet (établi en Pologne).
Délégué à la protection des données	Non désigné (section 9).
Instructions	L’instruction découle du Contrat de sous-traitance et des paramètres que le Client définit : le Client active le contrôle de livraison, configure des destinations d’alerte, enregistre un compte de test et met en place un portail client. Sans cette action, le traitement concerné n’a pas lieu.
Mesures techniques et organisationnelles	La section 8 et la page Mesures techniques et organisationnelles s’appliquent à chaque activité de traitement de la partie A. Les mesures particulières sont indiquées dans l’entrée concernée.

A.1 Contrôle de livraison – copie de contrôle des e-mails de formulaire

Champ	Mention
Finalité	Vérifier si l’e-mail issu du formulaire de contact du Client est effectivement envoyé et comment il est authentifié (SPF, DKIM, DMARC, alignement). Après une soumission de test active acceptée, sa copie doit arriver dans la boîte aux lettres de contrôle dans un délai d’attente réglable (actuellement 3 heures) ; à défaut, l’alerte « E-mail de test non reçu » est déclenchée. Les en-têtes servent en outre à déduire l’authenticité de l’e-mail de formulaire, le service de messagerie utilisé et l’adresse d’envoi pour la vérification des listes de blocage.
Condition préalable	Formule payante, domaine vérifié, activation par le Client. Le Client saisit sa propre adresse de contrôle avec un identifiant (de la forme « delivery+identifiant@… ») en copie cachée dans la notification de son formulaire. Sans boîte aux lettres de contrôle configurée, la fonction n’est pas disponible.
Catégories de personnes concernées	Visiteurs du site web du Client qui soumettent le formulaire du Client ; personnes dont un visiteur inscrit les données dans le message ; salariés du Client qui apparaissent comme destinataires dans les en-têtes.
Catégories de données à caractère personnel	Dans la boîte aux lettres de contrôle (chez le fournisseur de services de messagerie) : la copie complète de chaque e-mail de formulaire, y compris les demandes réelles avec nom, adresse e-mail, numéro de téléphone et texte libre, jusqu’à la suppression. Lus par la récupération : les en-têtes et au maximum les 8 premiers Ko du corps. Dans la base de données : heure de réception, rattachement au domaine et, le cas échéant, à l’exécution de test (delivery_log) ; le dernier résultat d’authentification par domaine avec le résultat SPF, DKIM et DMARC, l’alignement, le domaine de l’expéditeur, les domaines de signature et l’adresse du serveur de messagerie expéditeur (champ d’authentification du domaine dans domains). Le contenu, l’objet et l’adresse d’expéditeur du visiteur ne sont pas écrits dans la base de données.
Remarque sur le domaine de l’expéditeur	Si un formulaire indique l’adresse du visiteur comme expéditeur (une erreur de configuration que la vérification vise à mettre au jour), le résultat d’authentification contient le domaine de cette adresse, et non l’adresse elle-même. Lorsqu’un visiteur utilise un domaine personnel, celui-ci peut également constituer une donnée à caractère personnel. Il est écrasé lors de la réception suivante.
Source	Le formulaire sur le site web du Client, via la copie cachée saisie par le Client.
Base juridique (déterminée par le responsable du traitement)	Déterminée par le Client. Notre texte suggéré pour la politique de confidentialité du Client fonde la copie sur l’Art. 6(1)(f) RGPD (intérêt légitime à recevoir les demandes de manière fiable). Le Client informe ses visiteurs de ce flux de données ; le Contrat de sous-traitance l’y oblige.
Destinataires	Le fournisseur de services de messagerie qui exploite la boîte aux lettres de contrôle (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). La copie y est envoyée directement : elle n’arrive que si les enregistrements MX de notre domaine pointent vers cette boîte aux lettres (la liste de contrôle préalable au lancement le vérifie) ; via un transfert, elle n’atteint pas la boîte aux lettres. Sur la page du domaine, le Client ne voit que l’heure, le rattachement et le résultat d’authentification. Si le résultat d’authentification se dégrade, l’alerte adressée au Client et aux canaux qu’il a choisis mentionne le domaine de l’expéditeur s’il n’appartient pas au site web (A.3, 4.1).
Pays tiers	Dépend du fournisseur de services de messagerie ; voir section 4. Le contrat avec le fournisseur prévu et le fondement du transfert ne sont pas encore documentés.
Conservation	Après un traitement réussi, l’e-mail est marqué pour suppression et retiré de la boîte aux lettres lors du même passage, même s’il ne peut être rattaché à aucun domaine. La récupération s’exécute avec le contrôle d’état toutes les cinq minutes tant que la surveillance est activée dans l’espace d’administration (srv/cron_status.php, cfg/zustellung_lib.php). Si la récupération ou la suppression échoue, l’e-mail reste dans la boîte aux lettres jusqu’au prochain passage réussi. La même récupération supprime les rattachements dans delivery_log après 180 jours. Le résultat d’authentification subsiste aussi longtemps que le domaine.
Ce que prouve l’élément de preuve	Uniquement la réception, dans la boîte aux lettres de contrôle, de la copie rattachée à l’exécution de test concernée. Il ne prouve ni la réception par le destinataire réel ni une inscription dans le CRM. Une confirmation native de HubSpot n’est pas proposée.
MTO	Section 8. En particulier : le contenu n’est évalué qu’en mémoire ; aucun enregistrement du corps, de l’objet ni des adresses d’expéditeur complètes ; suppression indépendamment de la réussite du rattachement.

Le contrôle de livraison est la seule fonction par laquelle des messages réels des visiteurs de nos Clients nous parviennent. C’est pourquoi il s’agit d’un traitement pour le compte du Client et non d’un service relevant de notre propre responsabilité, et c’est pourquoi le temps passé dans la boîte aux lettres est la véritable mesure du risque : normalement quelques minutes ; si la récupération est perturbée, jusqu’à ce qu’elle fonctionne à nouveau. Les copies ne devraient pas contenir de catégories particulières de données à caractère personnel ; nous ne pouvons pas l’empêcher techniquement, car ce qu’écrit un visiteur dépend du visiteur.

A.2 Portail client et rapport mensuel aux abonnés

Champ	Mention
Finalité	Une agence (formule Business) présente à ses clients l’état de leurs domaines sous sa propre marque (portail à une adresse aléatoire, éventuellement protégé par mot de passe, éventuellement sous un sous-domaine propre à l’agence). Le client peut y commander un rapport mensuel par e-mail. Le rapport est envoyé au nom de l’agence.
Catégories de personnes concernées	Les clients de l’agence et leurs salariés qui commandent le rapport ; les personnes qui ouvrent le portail.
Catégories de données à caractère personnel	Abonné : adresse e-mail, langue, identifiant de confirmation, heure de la commande et adresse IP au moment de la commande, heure de la confirmation (double opt-in), heure du désabonnement, dernier mois envoyé (client_subscribers). Portail : nom, sélection de domaines, identifiant aléatoire, mot de passe uniquement sous forme de hachage, personne l’ayant créé, heure, révocation (client_portals). Les visites du portail apparaissent dans le journal des consultations de pages (B.2).
Source	Saisies par les abonnés eux-mêmes dans le portail.
Base juridique (déterminée par le responsable du traitement)	Le consentement de l’abonné, obtenu par une procédure de double opt-in ; le responsable du traitement est l’agence. Nous n’écrivons à personne qui ne s’est pas inscrit et n’a pas confirmé lui-même.
Destinataires	L’agence (voit ses abonnés) ; le fournisseur de services de messagerie (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA) pour l’e-mail de confirmation et le rapport.
Pays tiers	Via le fournisseur de services de messagerie ; voir section 4.
Conservation	Traitement de suppression nocturne (cfg/fristen_lib.php, partie « abonnés du portail ») : commandes jamais confirmées après 30 jours ; abonnés désabonnés trois ans après le désabonnement, comme preuve du consentement antérieur. Les abonnés confirmés qui ne se sont pas désabonnés subsistent aussi longtemps que l’espace de travail de l’agence existe. Un portail révoqué est seulement bloqué, pas supprimé ; ses abonnés ne reçoivent plus de rapports, mais leurs données subsistent (section 10). Les portails et abonnés disparaissent immédiatement avec l’espace de travail (fe_arbeitsbereich_daten_loeschen()). Les rapports envoyés restent dans la boîte d’envoi pendant 30 jours (B.25).
MTO	Section 8. En particulier : mot de passe du portail uniquement sous forme de hachage, tentatives de devinette limitées (dix par portail et par adresse IP, 50 par portail en 15 minutes) ; désabonnement en un clic dans chaque e-mail ; le portail n’affiche que l’état et les indicateurs clés, aucun constat individuel avec éléments de preuve.

A.3 Destinataires des alertes, personnes accusant réception et responsables désignés du Client

Champ	Mention
Finalité	Notifications de pannes et de modifications vers les destinations que le Client configure pour un domaine : e-mail, webhook, Slack, Discord, Microsoft Teams, Google Chat, Telegram. Par destination immédiatement, ou regroupées quotidiennement ou hebdomadairement, plus des destinations réservées aux escalades. Chaque notification de problème devient un incident, dont le destinataire peut accuser réception via un lien. Pour les formulaires surveillés, le Client peut désigner une personne responsable et une échéance.
Catégories de personnes concernées	Salariés et prestataires du Client que le Client saisit comme destination d’alerte ou désigne comme responsables ; personnes qui accusent réception d’un incident. Les membres de l’équipe disposant de leur propre compte apparaissent également dans la partie B.
Catégories de données à caractère personnel	Destination d’alerte : canal, adresse de destination (adresse e-mail, adresse de webhook ou de messagerie instantanée, identifiant de conversation Telegram), événements sélectionnés, mode d’envoi, secret de signature pour les webhooks, dernier envoi et dernière erreur (alerts). Journal d’envoi : destination, événements, statut, erreur, heure (alert_log). File de synthèse : lignes de notification et lien jusqu’à l’envoi (alert_queue). Incident : titre, lignes de notification, lien, identifiant d’accusé de réception, heure et nom ou adresse e-mail de la personne accusant réception tel que saisi dans le formulaire, sinon l’adresse du membre connecté (alert_incidents). Tentatives de remise d’escalade par incident et par destination : nombre de tentatives (au maximum cinq), heures de la dernière et de la prochaine tentative et de la réussite, référence à l’e-mail dans la boîte d’envoi, erreur (table alert_escalation_deliveries). Attribution : compte de la personne responsable et échéance (dans monitored_forms).
Contenu des notifications	Domaine, événement, une brève explication et un lien vers la page du domaine. Aucun contenu de messages de visiteurs.
Source	Saisies par le Client ; la personne accusant réception saisit elle-même son nom ; l’identifiant de conversation Telegram est créé lorsque le destinataire appuie sur « Start » dans le bot (B.32).
Base juridique (déterminée par le responsable du traitement)	Déterminée par le Client ; en règle générale, l’organisation de ses propres activités par le Client (Art. 6(1)(b) ou (f) RGPD à l’égard des salariés et prestataires du Client).
Destinataires	Les exploitants des canaux choisis ; voir 4.1. Alertes par e-mail via le fournisseur de services de messagerie (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
Pays tiers	Selon le canal choisi ; plusieurs fournisseurs sont établis aux États-Unis, Telegram hors de l’UE sans décision d’adéquation. Voir 4.1.
Conservation	Journal d’envoi après 90 jours (chaque nuit, fe_alert_log_aufraeumen() depuis srv/cron_status.php). Notifications de synthèse 30 jours après l’envoi (cfg/kanal_lib.php, à chaque envoi de synthèse). Incidents tant qu’ils ne sont pas résolus ; les incidents résolus 180 jours après leur résolution (cfg/vorfall_lib.php, traitement d’escalade), avec leurs tentatives de remise d’escalade. Destinations d’alerte et attributions jusqu’à leur suppression par le Client ou avec le domaine.
MTO	Section 8. En particulier : webhooks signés avec un secret distinct par destination ; accusé de réception uniquement après un clic (POST), afin que les aperçus de liens dans les programmes de messagerie instantanée ne déclenchent rien ; les alertes pendant une fenêtre de maintenance sont uniquement journalisées, pas envoyées.

A.4 Personnes visibles de manière fortuite sur les pages vérifiées du Client et dans les captures d’écran

Champ	Mention
Finalité	La vérification des domaines du compte du Client (analyse, surveillance, vérification active) lit les pages publiques du Client et réalise des captures d’écran des formulaires. Ce que la page elle-même affiche peut concerner des personnes qui n’ont rien à voir avec la vérification. Ces données sont générées de manière fortuite ; elles ne sont pas la finalité de la vérification.
Catégories de personnes concernées	Personnes dont le nom, la photo ou les coordonnées apparaissent sur la page vérifiée (interlocuteur à côté du formulaire, photos d’équipe sur la page d’accueil, informations des mentions légales).
Catégories de données à caractère personnel	Captures d’écran : la zone visible de la page d’accueil, chaque formulaire visible sous forme de découpe, et l’image de la page de suite après une soumission de test active ; stockées sous forme de fichiers en dehors du répertoire web, seule la référence figurant dans la base de données (scan_screenshots). Structure des formulaires : adresse de la page, sélecteur, noms de champs, types de champs, libellés de champs, indicateurs d’obligation et de visibilité, libellés des boutons d’envoi (forms, champ « field map ») ; aucune valeur de champ. Le scanner ne lit le début des champs cachés (jusqu’à 24 caractères) et des attributs data (jusqu’à 60 caractères) que pendant la vérification, afin de reconnaître les horodatages et les jetons ; seul le résultat est enregistré. Constats avec éléments de preuve (findings), synthèse avec titres de pages (scans). Si une adresse e-mail apparaît dans le formulaire comme destinataire, seul son domaine est enregistré, jamais l’adresse.
Source	Les pages publiques du domaine du Client, récupérées par le scanner.
Base juridique (déterminée par le responsable du traitement)	Déterminée par le Client pour le contenu de son propre site web. Pour nous, le traitement fait partie de la vérification commandée.
Destinataires	Le Client ; pour les agences, leur client via le portail ou un rapport en marque blanche ; toute personne qui reçoit un lien de rapport (rapports à des adresses aléatoires, non référencés dans les moteurs de recherche). Lorsque le type de formulaire n’est pas clair, un modèle de langage local sur notre propre serveur reçoit, pour la classification, la structure du formulaire avec le titre et l’adresse de la page et le texte visible du formulaire (jusqu’à 400 caractères) ; il ne reçoit pas d’images.
Pays tiers	Aucun.
Conservation	Résultats des vérifications d’un domaine pendant au maximum 13 mois ; la dernière vérification terminée par domaine subsiste (traitement de suppression nocturne, partie « anciens résultats de vérification »). Les formulaires, constats, références d’images et fichiers d’images disparaissent avec le résultat de la vérification. Avec le domaine, ces données disparaissent immédiatement (chaîne de suppression en B.15 ; exceptions à la section 6.4).
Limites du masquage	Les captures d’écran de la vérification complète ne masquent rien : elles montrent ce que la page montre à chaque visiteur. Les champs de formulaire sont vides lors de la récupération, car le scanner ne saisit rien ; des valeurs pré-remplies seraient visibles. Aucune capture d’écran n’est réalisée derrière une connexion (A.5). Les images des vérifications par navigateur masquent les champs de saisie (A.6).
MTO	Section 8. En particulier : les images ne peuvent être récupérées que via le rapport, et l’identifiant d’image d’autrui renvoie « introuvable » ; rapports avec noindex ; chaque vérification s’exécute dans son propre conteneur isolé.

Les mêmes données sont générées lors des vérifications sans compte (vérification gratuite, étude, vérification de prospects). Dans ces cas, il n’existe pas de Client pour le compte duquel nous agissons ; ces cas figurent donc dans la partie B (B.5, B.7, B.8).

A.5 Identifiants du compte de test pour l’analyse derrière la connexion

Champ	Mention
Finalité	Lire les formulaires qui n’apparaissent qu’après connexion (espace client, espace membres). Le scanner se connecte avec un compte de test que le Client a créé sur son propre site web et lit les pages indiquées. En dehors du formulaire de connexion, il ne soumet rien, n’y effectue aucun test actif, ne réalise aucune capture d’écran et ne visite pas d’adresses de déconnexion, de suppression ou de résiliation. Si le formulaire de connexion comporte un CAPTCHA, il s’arrête ; les CAPTCHA ne sont pas contournés.
Condition préalable	Domaine vérifié, formule payante, rôle de propriétaire ou d’administrateur, confirmation expresse que le compte est un compte de test. Au maximum cinq pages, toutes sur le même domaine.
Catégories de personnes concernées	La personne au nom de laquelle le compte de test est détenu (idéalement personne ; le Client devrait utiliser un compte fonctionnel) ; les personnes dont les données apparaissent sur les pages situées derrière la connexion.
Catégories de données à caractère personnel	Nom d’utilisateur et mot de passe du compte de test, uniquement chiffrés ; un indice pour le nom d’utilisateur (premier caractère et longueur) ; adresse de connexion, liste des pages, noms des champs de connexion, indicateur de réussite, personne l’ayant créé, heures, dernier résultat sous forme de code court (domain_logins). Pour une tâche en cours, une copie du texte chiffré (champ « login package » dans scan_jobs). Issu des pages situées derrière la connexion : structure des formulaires comme en A.4, sans captures d’écran et sans cookies.
Source	Saisis par le Client dans le compte.
Base juridique (déterminée par le responsable du traitement)	Déterminée par le Client. Le Client garantit qu’il est habilité à utiliser le compte de test.
Destinataires	Aucun. Ni le Client, ni l’assistance, ni l’interface de programmation ne peuvent lire les identifiants ; l’interface n’affiche que l’indice pour le nom d’utilisateur.
Pays tiers	Aucun.
Protection des identifiants	Le nom d’utilisateur et le mot de passe sont chiffrés immédiatement lors de l’enregistrement avec la clé publique du serveur d’analyse (X25519, HKDF-SHA256, AES-256-GCM ; le domaine est lié en tant que données associées, de sorte qu’un texte chiffré ne peut pas être rattaché à un autre domaine). Seul le serveur d’analyse possède la clé privée. Le serveur web, la base de données et les sauvegardes ne contiennent que le texte chiffré ; nous ne pouvons pas non plus le déchiffrer à cet endroit. Le serveur d’analyse ne déchiffre que pour l’exécution, ne transmet les identifiants au conteneur de vérification isolé que via l’entrée standard, supprime immédiatement la copie dans la tâche et ne l’écrit dans aucun résultat, journal ou texte d’erreur. Sur le chemin vers le site web du Client, ils ne sont protégés que par le chiffrement de ce site web ; les limites de ce transport sont exposées à la section 10.
Conservation	Identifiants enregistrés jusqu’à leur suppression par le Client. Lors de la suppression, le texte chiffré est écrasé par des données aléatoires de même longueur et la ligne est supprimée ; les tâches en attente sont vidées (fe_login_loeschen()). Avec le domaine, la ligne disparaît via une clé étrangère. Le serveur d’analyse efface les copies dans les tâches après l’exécution ; ce qui subsiste (tâche interrompue, serveur d’analyse hors service) est effacé par le contrôle d’état au plus tard après une heure (fe_login_aufraeumen(), partie « login_jobs »). Les sauvegardes de la base de données contiennent le texte chiffré jusqu’à l’expiration de la sauvegarde après 14 jours.
MTO	Section 8. En particulier : chiffrement asymétrique avec des clés distinctes ; liste de blocage pour les chemins de déconnexion et de suppression ; aucune capture d’écran derrière la connexion ; fonction réservée aux formules payantes et aux domaines vérifiés ; toute modification consignée dans le journal d’activité (sans les identifiants).

Nous n’avons délibérément prévu aucun moyen d’enregistrer des identifiants pour le serveur du Client, l’espace d’administration de son CMS ou ses comptes d’hébergement. Le compte de test est un compte visiteur sur le site web du Client, et non un accès au système du Client.

A.6 Parcours de formulaire configurés, vérifications par navigateur et sonde indépendante

Champ	Mention
Finalité	Un formulaire surveillé est parcouru dans un véritable navigateur (Chromium, WebKit ou les deux) jusqu’au moment précédant immédiatement la soumission : chargement de la page, exécution de clics préalables (au maximum cinq, jamais sur un champ de saisie ou un bouton d’envoi), remplissage des champs avec des valeurs manifestement synthétiques (comme une adresse sous l’extension réservée .invalid), progression dans les formulaires en plusieurs étapes. La vérification par navigateur ne soumet rien ; la soumission est techniquement bloquée dans le navigateur. En outre, mesures de temps et comparaisons visuelles du formulaire.
Catégories de personnes concernées	Comme en A.4 (personnes visibles sur la page du formulaire) ; salariés du Client saisis comme responsables (A.3).
Catégories de données à caractère personnel	Configuration : adresse du formulaire, sélecteurs, adresse d’entrée, étapes de clic, choix du navigateur, libellé, criticité, attribution, échéance (monitored_forms). Résultats par exécution : état, motif technique de l’échec, messages d’erreur nettoyés, mesures réseau et de temps, une image du formulaire au format JPEG de 32 Ko au maximum avec champs de saisie masqués (form_browser_runs). Observations par vérification (form_observations), séries temporelles (form_performance). Tâches avec une liste de cibles (champs « targets » et « result » dans scan_jobs).
Accès de test	Si le Client a enregistré un compte de test (A.5), la vérification complète l’utilise également pour les parcours de formulaire configurés. D’après le code mesuré, les vérifications par navigateur autonomes entre deux vérifications complètes fonctionnent sans compte de test.
Sonde indépendante	Un second point de contrôle situé ailleurs est envisagé, qui effectuerait un contrôle croisé avant une alerte. Il recevrait le domaine, la configuration nettoyée et l’identifiant de la tâche, aucune saisie de visiteur ni aucun identifiant de connexion. Il n’est actuellement pas configuré (désactivé par défaut). Sans la sonde, il n’y a pas d’élément de preuve depuis un second emplacement ; une alerte repose alors sur notre propre mesure.
Source	Configurés par le Client ; résultats issus de la récupération de la page du Client.
Base juridique (déterminée par le responsable du traitement)	Déterminée par le Client pour le contenu de son site web et pour les responsabilités de ses salariés.
Destinataires	Le Client ; lorsqu’une sonde est mise en place, son exploitant (actuellement personne).
Pays tiers	Aucun.
Conservation	Résultats des exécutions dans le navigateur, tâches de navigateur terminées et séries temporelles après 13 mois (traitement de suppression nocturne, parties « browser_runs », « browser_jobs », « form_performance »). Configurations jusqu’à la suppression du domaine (elles peuvent être modifiées ou désactivées individuellement, mais pas supprimées) ; avec le domaine, elles disparaissent, ainsi que les exécutions, observations et séries temporelles, via des clés étrangères.
Ce que prouve la mesure	Des temps et des états issus de notre navigateur de vérification. Ils ne mesurent pas ce que vivent les visiteurs réels et ne prouvent ni des taux de complétion ni des demandes perdues.
MTO	Section 8. En particulier : soumission techniquement empêchée ; uniquement des adresses sur le même domaine ; images masquées ; conteneur de vérification isolé.

A.7 « Fix it for me » – code de formulaire collé

Champ	Mention
Finalité	Le Client colle le code de son formulaire ; un modèle de langage fonctionnant sur notre propre matériel y intègre le module de protection. En retour, le Client reçoit le fichier modifié, un correctif, le résultat d’une vérification syntaxique et une indication précisant si l’appel de vérification a effectivement été intégré. Sans code collé, le service fournit un module prêt à l’emploi avec les noms de champs de la dernière analyse.
Catégories de personnes concernées	Personnes dont les données figurent par hasard dans le code collé (comme une adresse de destinataire, des noms dans des commentaires, des identifiants pour un serveur de messagerie).
Catégories de données à caractère personnel	Le code collé, au maximum 30,000 caractères. Dans la base de données, uniquement une entrée dans le journal d’activité (action « fix_ai » avec espace de travail et heure), qui est décomptée de la limite quotidienne de actuellement dix appels par espace de travail.
Source	Collé par le Client.
Base juridique	Exécution du contrat avec le Client (Art. 6(1)(b) RGPD) pour le code lui-même ; pour les données de tiers qui y figurent par hasard, le Client détermine la base juridique.
Destinataires	Aucun. Le modèle de langage fonctionne sur notre propre serveur d’analyse au sein du réseau interne ; aucun service d’IA externe, pas même en solution de repli.
Pays tiers	Aucun.
Conservation	Le code n’est pas enregistré. Un fichier temporaire est créé pour la vérification syntaxique et supprimé immédiatement après. L’entrée dans le journal d’activité est supprimée après 365 jours.
Remarque à l’intention du Client	Le code contenant des mots de passe, des clés API ou des données à caractère personnel devrait être nettoyé avant d’être collé. Nous ne vérifions pas le contenu.
MTO	Section 8. En particulier : uniquement pour les propriétaires et administrateurs disposant d’une formule payante ; le code collé est transmis au modèle en étant marqué comme données et n’est jamais exécuté ; aucun téléversement vers des serveurs de tiers.

A.8 Marque blanche et interlocuteurs de l’agence

Champ	Mention
Finalité	Les rapports, rapports courts, journaux de preuve et le portail client d’une agence (formule Business) apparaissent sous sa marque, sur demande sous un sous-domaine propre à l’agence.
Catégories de personnes concernées	Interlocuteurs de l’agence dont le nom ou les coordonnées apparaissent dans la ligne de contact.
Catégories de données à caractère personnel	Nom de l’entreprise, site web, ligne de contact, note au client, couleur d’accent, apparence, fichier du logo, option de mention de formexposed, domaine propre avec identifiant de vérification et état de vérification (workspace_branding).
Source	Saisies par l’agence.
Base juridique	Exécution du contrat avec l’agence (Art. 6(1)(b) RGPD). Lorsque la ligne de contact nomme des salariés de l’agence, l’agence détermine la base juridique.
Destinataires	Toute personne à qui l’agence remet un rapport, un rapport court ou un lien de portail.
Pays tiers	Aucun.
Conservation	Jusqu’à modification par l’agence ; la marque et le fichier du logo disparaissent avec l’espace de travail (fe_arbeitsbereich_daten_loeschen()). Un domaine propre dont la vérification DNS échoue pendant sept jours est désactivé. Le domaine propre est désactivé par défaut.
MTO	Section 8.

A.9 Décomptes, indicateurs d’état et erreurs de champs issus du plugin et de l’extension

Champ	Mention
Finalité	Une fois par jour, le plugin WordPress et l’extension TYPO3 transmettent des chiffres sur les formulaires du site web connecté : soumissions bloquées par motif, soumissions, e-mails envoyés et en échec, indicateurs d’état des paramètres des formulaires, demandes enregistrées par source et durée de conservation. Facultatifs, désactivés par défaut : événements de formulaire et catégories d’erreurs de champs par position de champ. Ces chiffres alimentent « La protection en chiffres », le rapport mensuel, l’alerte de silence et les avertissements relatifs aux paramètres risqués.
Qualification	Les chiffres sont conçus pour ne décrire aucune personne. Nous les mentionnons dans la partie A parce qu’ils résultent d’événements sur le site web du Client déclenchés par les visiteurs du Client ; à notre avis, ils ne constituent des données à caractère personnel que dans des cas limites (un site web avec très peu de soumissions un jour donné). La transmission elle-même (clés, versions, hôte) figure dans la partie B (B.20).
Catégories de personnes concernées	Visiteurs du site web du Client qui soumettent un formulaire.
Catégories de données à caractère personnel	Chiffres quotidiens par hôte : bloqués au total et par motif, soumissions, e-mails envoyés et en échec, catégorie d’erreur de l’envoi d’e-mails (une seule de quatre catégories, jamais le texte de l’erreur, car il peut contenir des adresses de destinataires), décomptes des réponses reCAPTCHA, demandes supprimées et libérées (plugin_stats). État : versions issues d’une liste fixe de plugins de formulaires, de CAPTCHA et de messagerie, indicateurs de paramètres sous forme de nombres, durées de conservation (plugin_health). Notifications de modification : nom et version d’un plugin mis à jour (plugin_changes). Facultatif : compteurs par formulaire et par jour avec catégories d’erreurs par position de champ (form_metrics). Jamais : saisies, noms de champs, mots de passe, fichiers, adresses e-mail, noms, adresses IP ou identifiants persistants de visiteurs.
Source	Le plugin sur le site web du Client, via une interface de programmation utilisant le secret de connexion du site web.
Base juridique (déterminée par le responsable du traitement)	Déterminée par le Client ; le Client décide d’activer ou non les décomptes facultatifs et de la manière d’informer ses visiteurs.
Destinataires	Le Client. Les domaines des liens figurant dans les messages bloqués alimentent la protection collective (B.21).
Pays tiers	Aucun.
Conservation	Chiffres quotidiens, notifications de modification et compteurs de formulaires après 13 mois (traitement de suppression nocturne, parties « plugin_stats » et « form_metrics »). Les indicateurs d’état sont écrasés à chaque transmission. Toutes les données du plugin relatives à un hôte disparaissent dès qu’aucun domaine du système ne renvoie plus à cet hôte (immédiatement lors de la suppression du dernier domaine ; données héritées chaque nuit, partie « orphan_hosts »).
Ce que prouvent les chiffres	Ce que le plugin a compté. Ils ne prouvent ni des taux de complétion ni des demandes perdues.
MTO	Section 8. En particulier : acceptation uniquement avec la paire de clés liée au site web ; seuls les clés et nombres connus sont acceptés, tout le reste est rejeté ; les jours en dehors d’une fenêtre de 14 jours sont refusés.

A.10 Limite : ce qui reste uniquement sur le site web du Client

Les fonctions suivantes du plugin WordPress et de l’extension TYPO3 traitent des données exclusivement sur le serveur du Client. Elles ne nous parviennent pas, et nous n’y avons pas accès. L’exploitant du site web en est seul responsable ; il décide de l’activation, des durées de conservation et de la manière d’informer ses visiteurs. À cette fin, le plugin propose des paragraphes pour la politique de confidentialité de l’exploitant.

Fonction	Ce qui est traité localement	Conservation du côté du Client
Quarantaine	Soumissions arrêtées avec leur motif, pouvant être libérées par e-mail à l’adresse du site web	14 jours
Filet de sécurité	Soumissions dont l’e-mail de formulaire a échoué, en vue d’un nouvel envoi (activé par défaut)	30 jours
Énigme arithmétique au lieu de reCAPTCHA	Calcul à effectuer dans le navigateur du visiteur, sans service tiers (désactivé par défaut)	–
Paramètres de conservation	Suppression des demandes enregistrées dans les plugins de formulaires après la durée choisie par l’exploitant (désactivé par défaut)	selon la configuration
Limitation du débit	un identifiant de courte durée dérivé de l’adresse IP, non transmis à nous	courte durée
Compteurs quotidiens locaux	Valeurs des compteurs avant transmission	au maximum 14 jours
Enregistreur pour les administrateurs	sélecteurs techniques et étapes de navigation dans le stockage de session du navigateur d’un administrateur connecté ; les saisies ne sont pas lues. Seule la configuration sélectionnée est transmise (alors A.6)	au maximum 15 minutes
Aide aux visiteurs	activable séparément ; n’enregistre aucun brouillon et ne renvoie rien automatiquement	–
Observation des nouvelles règles anti-spam	les correspondances supplémentaires sont comptées localement, sans activation automatique	sept jours

A.11 Protection des formulaires (formconfirmed)

Champ	Mention
Finalité	Évaluation des soumissions effectuées au moyen de formulaires sur les sites web du Client afin de détecter les soumissions automatisées : émission et vérification de tâches (preuve de travail), jetons de vérification à usage unique, durée de remplissage, champ piège, requêtes répétées ; à la demande du Client, évaluation du texte du message par un modèle de langage. Uniquement pour les Clients qui activent la protection des formulaires.
Catégories de personnes concernées	Les visiteurs des sites web du Client qui ouvrent une page comportant un formulaire protégé ou qui l’envoient.
Catégories de données à caractère personnel	Adresse IP (enregistrée uniquement sous forme tronquée et hachée avec une clé qui change chaque jour), adresse et domaine de la page, horodatages et durée de remplissage, champ piège rempli oui/non, identifiant du navigateur dans le journal du serveur web ; uniquement si le contrôle du contenu est activé, le texte du message (en mémoire vive uniquement).
Origine	Navigateur du visiteur (tâche, jeton de vérification) ; serveur du Client (demande de vérification, le cas échéant texte).
Destinataires	Le Client (score, action, motifs). Aucun autre ; aucun sous-traitant ultérieur pour ce traitement.
Pays tiers	Aucun.
Durée de conservation	Identifiant haché 1 heure ; jetons de vérification utilisés 11 minutes au maximum ; résultats de vérification sans adresse IP ni texte 30 jours ; chiffres quotidiens 400 jours ; journal du serveur web 14 jours ; texte : aucun enregistrement.
MTO	Section 8 ; en outre troncature et hachage avec une clé quotidienne, tâches signées, usage unique, modèle de langage sur notre propre matériel sans journalisation du texte.

4. Partie A – destinataires, sous-traitants ultérieurs et transferts vers des pays tiers

Le tableau suivant énumère les destinataires auxquels nous faisons nous-mêmes appel et qui peuvent recevoir des données de la partie A. La liste faisant foi, mise à jour en continu, est la page Sous-traitants ultérieurs ; si elle diffère de ce tableau, il s’agit d’un constat, et non d’une question de mise en forme.

Destinataire	Ce qu’il reçoit	Pays tiers	Fondement	État
Namecheap, Inc. (Private Email), Phoenix, Arizona, USA	Boîte aux lettres de contrôle du contrôle de livraison (A.1) ; envoi des e-mails d’alerte (A.3), des confirmations et des rapports aux abonnés du portail (A.2)	Lieu du traitement encore à vérifier ; voir la page « Sous-traitants ultérieurs »	Contrat de sous-traitance ; fondement du transfert encore à vérifier	En suspens. Le contrat applicable, les lieux effectifs de traitement et le fondement du transfert ne sont pas encore documentés. Ce registre ne confirme ni une certification ni un contrat conclu.
Namecheap, Inc. (bureau d’enregistrement, DNS ; transfert d’e-mails jusqu’à la mise en place de la boîte aux lettres)	Jusqu’à la mise en place de la boîte aux lettres, le courrier entrant général adressé à notre domaine ; pas les copies issues du contrôle de livraison, qui n’arrivent qu’avec des enregistrements MX pointant directement vers la boîte aux lettres (A.1)	États-Unis	à vérifier : certification au titre du cadre de protection des données UE-États-Unis (EU-US Data Privacy Framework) ou clauses contractuelles types	En usage ; fondement en suspens.
Notre propre serveur d’analyse avec un modèle de langage local	Structure des formulaires pour la classification (A.4), code collé (A.7), accès de test déchiffré uniquement pendant l’exécution (A.5)	–	Exploité par nous, pas un tiers	En usage.
Sonde indépendante sur un second site	Domaine, configuration nettoyée, identifiant de la tâche (A.6)	selon l’emplacement	à déterminer avant la mise en service	Non configurée.

Hébergement : aucun tiers. L’application, la base de données, les captures d’écran et les sauvegardes sont conservées sur nos propres serveurs en Pologne. Si nous passons à un centre de données ou à un fournisseur de cloud, ce paragraphe devra être réécrit.

4.1 Canaux d’alerte choisis par le Client

Outre les destinataires auxquels nous faisons appel, il existe des canaux que le Client choisit pour ses alertes (A.3). Notre serveur déclenche la transmission ; le Client détermine la destination et le fournisseur. Le choix d’un canal ne nous décharge pas de nos propres obligations en tant que sous-traitant. Le rôle, le contrat et les garanties requises pour les pays tiers doivent être déterminés pour chaque fournisseur ; pour les services de messagerie instantanée, cela n’a pas encore été achevé (question ouverte pour l’examen juridique).

Canal	Ce qui est envoyé	Siège du fournisseur
E-mail	Domaine, événement, explication, lien ; à l’adresse saisie	via Namecheap, Inc. (Private Email), Phoenix, Arizona, USA
Webhook vers une adresse librement choisie	Événement au format JSON (domaine, événements, lignes, lien, horodatage), signé avec le secret de la destination	déterminé par le Client
Slack, Discord, Microsoft Teams, Google Chat	la même notification sous forme de message de messagerie instantanée vers l’adresse de webhook saisie	principalement États-Unis
Telegram	destination choisie par le Client ; nous envoyons le message via notre bot à l’identifiant de conversation associé	hors de l’UE, sans décision d’adéquation ; le fondement du transfert est une question ouverte pour l’examen juridique

En aucun cas le contenu d’un message de visiteur n’est envoyé. Les notifications contiennent le domaine, l’événement et le lien.

5. Partie B – Art. 30(1) : traitements sous notre propre responsabilité

Responsable du traitement pour l’ensemble de cette partie : LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Pologne, contact@lukaswojcik.com. Aucun représentant requis (établi dans l’Union). Aucun délégué à la protection des données désigné (section 9). Mesures techniques et organisationnelles : section 8 et la page Mesures techniques et organisationnelles. La manière dont les personnes concernées exercent leurs droits est décrite sur la page Accès, effacement et vos autres droits ; les titulaires de compte peuvent télécharger eux-mêmes leurs données sous forme de fichier (Paramètres).

Lorsque nous nous fondons sur l’intérêt légitime (Art. 6(1)(f) RGPD), nous nommons l’intérêt et la raison pour laquelle un moyen moins intrusif ne suffit pas. La mise en balance est notre appréciation ; elle fait partie de l’examen juridique.

B.1 Visiteurs de notre site web – journaux du serveur web

Champ	Mention
Finalité	Exploitation et sécurité du site web et de l’application : diffusion, dépannage, détection des attaques et des surcharges.
Catégories de personnes concernées	Toute personne qui ouvre une page de formexposed.com ou form.exposed, y compris les visiteurs de pages de Clients dont le navigateur charge notre image de badge (B.18), les destinataires qui ouvrent un lien de rapport ou d’accusé de réception, et les sites web dont le plugin appelle notre interface.
Catégories de données à caractère personnel	Adresse IP complète, heure, adresse demandée, code de statut, octets transférés, page de provenance (référent), identifiant du navigateur (user agent).
Lieu d’enregistrement	Journaux d’accès du proxy en amont et du serveur web sous forme de fichiers sur le serveur web, et non dans la base de données.
Source	Le navigateur ou le programme à l’origine de la requête.
Base juridique	Art. 6(1)(f) RGPD. Intérêt : exploitation sûre et ininterrompue. Mise en balance : sans l’adresse complète, les requêtes répétées d’un même expéditeur ne peuvent pas être reliées et les attaques ne peuvent pas être repoussées ; une adresse tronquée ne permet pas cette distinction. Les journaux ne sont pas combinés avec d’autres données et sont supprimés après une courte durée.
Destinataires	Aucun.
Pays tiers	Aucun.
Conservation	14 jours : rotation quotidienne sur 14 générations, puis écrasement (service de rotation des journaux du système, et non le traitement de suppression nocturne de l’application).
MTO	Section 8.

B.2 Journal des consultations de pages de l’application

Champ	Mention
Finalité	Sécurité et détection des abus (qui demande quoi et à quelle fréquence), traçabilité des accès aux comptes, statistiques d’utilisation simples sans service d’analyse.
Catégories de personnes concernées	Tous les visiteurs du site web et utilisateurs de l’application lors de consultations de pages réelles (pas de requêtes en arrière-plan, pas d’envois de formulaires).
Catégories de données à caractère personnel	Adresse IP complète, pays qui en est déduit lors de l’écriture (base de géolocalisation locale, aucune requête auprès d’un tiers), identifiant de compte pour les utilisateurs connectés, adresse demandée et page de provenance (les jetons d’accès qu’elles contiennent, comme ceux des liens de rapport ou de portail, sont masqués), identifiant du navigateur ainsi que le type d’appareil, le système d’exploitation et le navigateur qui en sont déduits, langue, heure (access_logs). Pendant « Voir en tant que client » (B.14), aucun identifiant de compte n’est défini, afin que les consultations de pages de l’assistance n’apparaissent pas dans le journal du Client.
Source	La requête du navigateur.
Base juridique	Art. 6(1)(f) RGPD. Intérêt : prévention des abus et traçabilité. Mise en balance : comme en B.1 ; la durée de conservation est plus longue, car les schémas d’abus ne deviennent visibles que sur plusieurs semaines. La question de savoir si l’adresse IP devrait être tronquée ou la durée de conservation raccourcie est une question ouverte pour l’examen juridique.
Destinataires	Aucun. Les titulaires de compte reçoivent leurs propres consultations de pages dans l’export de données.
Pays tiers	Aucun.
Conservation	60 jours (chaque nuit entre 03:00 et 03:05, srv/cron_status.php, paramètre « journal des consultations de pages »).
MTO	Section 8. L’adresse IP n’est reprise d’un en-tête transféré que si la requête provient de notre propre proxy en amont, et uniquement l’entrée ajoutée par ce proxy ; sinon, chacun pourrait indiquer sa provenance à sa guise.

B.3 Cookies et stockage dans le navigateur

Champ	Mention
Finalité	Stockage techniquement nécessaire : session, protection contre la falsification de requêtes intersites (CSRF), décompte des limites pour les vérifications sans compte, connexion, maintien de la connexion sur demande, affichage clair ou sombre.
Catégories de personnes concernées	Visiteurs et utilisateurs de formexposed.com.
Catégories de données à caractère personnel	Cookie de session bpid (identifiant de session ; prend fin à la fermeture du navigateur ; HttpOnly, SameSite=Lax, Secure via HTTPS). Cookie bp_remember uniquement après avoir choisi « Rester connecté » (sélecteur et vérificateur ; 30 jours). Stockage local bp_theme (clair, sombre ou système). Dans l’espace d’administration, en outre des paramètres d’affichage locaux des exploitants. Pour les limites, un hachage est formé à partir de l’identifiant de session ; l’identifiant lui-même n’est pas enregistré.
Non déposés	Aucun cookie d’analyse, de publicité ou de suivi. Le programme partenaires (B.33) fonctionne sans cookie. L’image du badge sur les pages des Clients ne dépose aucun cookie (B.18). reCAPTCHA peut déposer des cookies de Google lors de l’envoi d’un formulaire protégé (B.23).
Base juridique	Accès à l’équipement terminal : strictement nécessaire au service demandé par l’utilisateur (§ 25(2) no. 2 TDDDG, la loi allemande sur la protection des données dans les télécommunications et les services numériques ; Art. 399(3) PKE, la loi polonaise sur les communications électroniques (Prawo komunikacji elektronicznej)). Traitement : Art. 6(1)(b) RGPD (compte) et (f) (sécurité, limites).
Destinataires	Aucun.
Pays tiers	Aucun.
Conservation	Session ; 30 jours pour le jeton de maintien de connexion. Le traitement nocturne supprime les jetons de maintien de connexion expirés dans la base de données (remember_tokens) ; lors de la déconnexion, du changement de mot de passe et de la révocation d’un appareil, immédiatement.
MTO	Section 8.

B.4 Vérification gratuite sans compte – acceptation, limites et surveillance des abus

Champ	Mention
Finalité	Toute personne peut faire vérifier un domaine sans compte. Pour que le champ de saisie ne devienne pas une arme contre des sites web de tiers, des limites échelonnées s’appliquent : une vérification anonyme par domaine sur sept jours (ensuite, le même rapport), des limites par adresse IP et par session sur 24 heures, une limite quotidienne pour l’ensemble du système, un blocage des domaines très récents, liste de blocage et opt-out, adresses publiques uniquement. Les schémas suspects sont consignés et signalés à l’exploitant. Les limites par adresse IP, par session et pour l’ensemble du système, chacune comptée séparément, s’appliquent également à la vérification depuis le plugin sans compte (un plugin disposant d’une paire de clés liée compte par site web au lieu de par adresse) et à l’opt-out (B.30) ; l’outil d’en-têtes gratuit (B.9) a ses propres limites par adresse IP et par jour et pour l’ensemble du système.
Catégories de personnes concernées	Personnes qui déclenchent une vérification, une requête à l’outil d’en-têtes ou un opt-out ; serveurs sur lesquels un plugin est installé.
Catégories de données à caractère personnel	Journal de chaque requête : source (vérification, plugin, outil d’en-têtes, opt-out), adresse IP complète, hachage de l’identifiant de session, hôte vérifié, pays déduit de l’adresse IP, accepté ou refusé avec motif, heure (check_throttle). Anomalies : type (adresse IP, session, pays, système), clé (pour le type « IP », l’adresse IP complète), schéma, gravité, brève description, heures de détection et de résolution, personne ayant résolu (abuse_flags). Tâche : hôte, mode, niveau de confiance et un hachage de session tronqué comme identifiant du demandeur (scan_jobs). Rapport : identifiant aléatoire, hôte, langue, expiration, première consultation, nombre de consultations (reports). Âge du domaine mis en cache issu de la consultation du registre (domain_age_cache).
Source	La saisie de la personne ; sa requête ; consultation du registre (RDAP) pour l’âge du domaine.
Base juridique	Exécution de la vérification demandée : Art. 6(1)(b) RGPD (utilisation de la vérification gratuite selon les Conditions d’utilisation) ; à titre subsidiaire, (f). Limites et surveillance : Art. 6(1)(f). Intérêt : empêcher que le service soit utilisé comme outil contre des sites web de tiers ou comme canon à spam. Mise en balance : sans lien avec l’adresse et la session, les limites ne pourraient pas être appliquées ; la durée de sept jours est aussi courte que la plus longue limite comptée à partir de celle-ci.
Destinataires	Google (reCAPTCHA lors de l’envoi, B.23). Pour l’âge du domaine, le scanner interroge le service de redirection RDAP rdap.org, qui renvoie vers le registre compétent ; seul le nom de domaine est transmis. Lorsqu’une anomalie survient, l’exploitant reçoit un signal via Telegram sans aucune variable (ni hôte, ni adresse). Le rapport peut être consulté par toute personne disposant de son lien aléatoire.
Pays tiers	États-Unis via reCAPTCHA (B.23).
Conservation	Journal des requêtes 7 jours (chaque nuit, srv/cron_status.php). Anomalies résolues 90 jours après leur résolution ; celles non résolues subsistent jusqu’à ce que quelqu’un les résolve (section 10). Les rapports anonymes expirent après 30 jours ; le traitement nocturne supprime alors le rapport, la tâche, le résultat de la vérification, les formulaires, les constats et les images (fe_reports_aufraeumen()). Un administrateur peut débloquer manuellement les entrées d’une adresse ; cela supprime son journal des dernières 24 heures.
MTO	Section 8. Arrêt d’urgence de toutes les vérifications anonymes dans l’espace d’administration ; mécanisme de contre-pression qui n’accepte aucune nouvelle vérification gratuite en cas d’arriéré.

B.5 Vérification de sites web de tiers par le robot d’exploration

Champ	Mention
Finalité	Vérification de sécurité des formulaires de contact publics : protections contre le spam et les abus, caractéristiques de protection des données et d’accessibilité, scripts de tiers intégrés, comportement après un refus dans la bannière de cookies, affichage mobile. S’applique aux vérifications sans compte (B.4), aux domaines d’un compte qui ne sont pas encore vérifiés, et sert de base à l’étude (B.7) et à la vérification de prospects (B.8). Pour les domaines vérifiés d’un compte, nous agissons pour le compte du Client (A.4).
Comportement du robot d’exploration	Son propre identifiant avec un renvoi vers la page du robot d’exploration ; lit robots.txt avant la vérification et s’arrête si une règle disallow couvre la page d’accueil (de même si robots.txt est inaccessible ou en cas d’erreur serveur) ; les règles disallow portant sur des sous-chemins individuels ne sont pas respectées séparément. Le pouls des formulaires, la récupération de la preuve, l’outil d’en-têtes et la recherche de fichiers exposés ne lisent pas robots.txt. Au maximum huit pages publiques par vérification, plus jusqu’à trois pages avec un clic sur « Refuser » dans la bannière de cookies, jusqu’à trois pages en affichage mobile, des sondes actives pour les domaines vérifiés et jusqu’à cinq pages derrière une connexion (A.5) ; les pages sont chargées l’une après l’autre, pas en parallèle ; adresses publiques uniquement, aucun réseau interne, les redirections sont vérifiées à nouveau ; la liste de blocage et l’opt-out sont vérifiés avant l’acceptation et une seconde fois dans le scanner. Passif : sans preuve de contrôle, rien n’est soumis pour les Clients (exception : vérifications internes de nos propres domaines de test et de démonstration, B.6).
Catégories de personnes concernées	Exploitants des sites web vérifiés (lorsqu’il s’agit de personnes physiques, comme des entrepreneurs individuels) ; personnes visibles de manière fortuite sur les pages vérifiées.
Catégories de données à caractère personnel	Comme en A.4 : adresses et titres des pages, structure des formulaires (noms, types et libellés de champs, aucune valeur de champ), protections, scripts de tiers (adresses ; les identifiants de compte des pixels et outils d’enregistrement sont remplacés avant l’enregistrement), comportement de la bannière de cookies, captures d’écran (zone visible de la page d’accueil, formulaires). Si une adresse de destinataire apparaît dans le formulaire, uniquement son domaine (scans, forms, findings, scan_screenshots).
Source	Pages accessibles au public.
Base juridique	Art. 6(1)(f) RGPD. Intérêt : effectuer la vérification de sécurité demandée ; alerter les exploitants de sites web sur des faiblesses susceptibles de nuire à leurs visiteurs. Mise en balance : seul ce que voit chaque visiteur est lu, dans une faible mesure et sans rien soumettre ; l’exploitant peut à tout moment exclure définitivement son domaine sans justificatif. L’information au titre de l’Art. 14 RGPD est fournie via la page du robot d’exploration, l’opt-out et la Politique de confidentialité ; la question de savoir si cela suffit au regard de l’Art. 14(5)(b) est une question ouverte pour l’examen juridique.
Destinataires	La personne qui déclenche le rapport et toute personne à qui elle remet le lien aléatoire ; le modèle de langage local sur notre propre serveur lorsque le type de formulaire n’est pas clair (structure du formulaire, titre et adresse de la page, texte visible du formulaire). Les avertissements de vulnérabilité issus des versions de plugins n’apparaissent jamais dans les rapports anonymes.
Pays tiers	Aucun.
Conservation	Anonyme : 30 jours (B.4). Vérification de prospects : 90 jours (B.8). Étude : jusqu’à la publication (B.7). Domaine dans un compte : au maximum 13 mois, la dernière vérification subsiste ; immédiatement avec le domaine. Vérifications internes par l’exploitant sans domaine et sans rapport (comme celles créées depuis la ligne de commande) : aucune durée de conservation (section 10). Les fichiers temporaires sur le serveur d’analyse sont supprimés après chaque exécution.
MTO	Section 8. En particulier : conteneur de vérification distinct avec privilèges réduits, système de fichiers en lecture seule, limite de mémoire et son propre réseau ; double contrôle de la cible.

B.6 Soumissions de test actives

Champ	Mention
Finalité	Vérifier si un formulaire de contact accepte une soumission sans protection, si le CAPTCHA, le piège (honeypot), le jeton, la validation de l’adresse e-mail et la limitation du débit agissent côté serveur, et si des en-têtes peuvent être injectés.
Condition préalable	Pour les Clients, uniquement pour les domaines dont la preuve de contrôle a été apportée (enregistrement DNS, balise meta, fichier ou plugin connecté) ; en outre, l’exploitant utilise un outil interne en ligne de commande pour créer des vérifications de niveau « vérifié » pour nos propres domaines de test et de démonstration. Uniquement lorsque l’interrupteur global est activé, uniquement pour un formulaire classé de manière fiable comme formulaire de contact général. Jamais pour des commandes, réservations, inscriptions, newsletters, paiements, téléversements de fichiers, champs obligatoires avec des données à caractère personnel réelles, ni pour des domaines d’autorités publiques, d’établissements de santé ou d’enseignement.
Catégories de personnes concernées	Salariés du Client qui reçoivent les e-mails de formulaire.
Catégories de données à caractère personnel	La soumission de test ne contient aucune donnée à caractère personnel : expéditeur « FormExposed Security Scanner », notre propre adresse d’expéditeur ou une adresse sous .invalid, une ligne d’objet identifiée et un texte dans la langue de la page avec un renvoi vers la page du robot d’exploration et l’opt-out ainsi que le numéro de vérification. Enregistrés par nous : la réponse de la page, les constats, une image de la page de suite (comme en A.4).
Étendue	Au maximum cinq soumissions par vérification (paramètre, valeur par défaut 5) ; récurrentes selon la fréquence de vérification de la formule, quotidiennes dans la formule la plus élevée.
Source	L’instruction du Client.
Base juridique	Exécution du contrat avec le Client (Art. 6(1)(b) RGPD) ; les soumissions sont adressées au propre formulaire du Client. Pour les destinataires chez le Client : l’organisation du Client.
Destinataires	Le Client (son e-mail de formulaire).
Pays tiers	Aucun de notre fait.
Conservation	Résultats comme en A.4.
MTO	Section 8. L’injection d’en-têtes est uniquement détectée, jamais effectuée avec un destinataire réel ; la validation de l’adresse e-mail n’utilise qu’un domaine qui ne peut pas exister.

B.7 Étude « Indice de sécurité des formulaires »

Champ	Mention
Finalité	Statistiques sur la protection des formulaires de contact dans un pays ou un secteur. Seuls des totaux sont publiés, sans noms de sites web ; les segments uniquement à partir de 20 pages comportant un formulaire.
Catégories de personnes concernées	Exploitants des sites web figurant sur la liste ; personnes visibles de manière fortuite.
Catégories de données à caractère personnel	Comme en B.5, uniquement en mode passif. En outre, la liste : hôte, segment, statut, tâche (study_domains) ; étude avec titre, pays, totaux des résultats (studies).
Source	Une liste de sites web publics établie par l’exploitant ; les pages elles-mêmes.
Base juridique	Art. 6(1)(f) RGPD. Intérêt : déclarations statistiques sur l’état de la sécurité des formulaires. Mise en balance : passif, ralenti (peu de tâches par exécution), la liste de blocage et l’opt-out s’appliquent, publication uniquement sous forme de totaux, les données brutes sont supprimées.
Destinataires	Le public, uniquement des totaux.
Pays tiers	Aucun.
Conservation	Les données brutes (résultats des vérifications, formulaires, constats, images, tâches) sont supprimées lors de la publication (fe_studie_veroeffentlichen()). La liste des hôtes avec leur segment subsiste ensuite ; il n’existe aucune durée de conservation pour celle-ci ni pour les études qui ne sont jamais publiées (section 10). L’exploitant décide quelles listes sont vérifiées et si les études sont publiées.
MTO	Section 8.

B.8 Vérification de prospects (mode prospection pour les agences)

Champ	Mention
Finalité	Une agence (formule Business) vérifie de manière passive le site web d’un prospect et reçoit un rapport court sous sa marque ainsi que le rapport passif. Nous ne contactons personne ; l’agence transmet elle-même le lien.
Catégories de personnes concernées	Exploitant du site web vérifié ; personnes visibles de manière fortuite ; salariés de l’agence qui déclenchent la vérification.
Catégories de données à caractère personnel	Comme en B.5, uniquement en mode passif. En outre : espace de travail, personne déclenchant la vérification, hôte, identifiant aléatoire du rapport, heure (prospect_checks).
Source	La saisie de l’agence ; les pages publiques.
Base juridique	Art. 6(1)(f) RGPD (notre intérêt à fournir le service et l’intérêt de l’agence à une approche fondée). Les rôles de l’agence et de nous-mêmes ainsi que les obligations de l’agence lors de la transmission du rapport sont des questions ouvertes pour l’examen juridique : si l’agence envoie le rapport par e-mail sans sollicitation ou passe un appel téléphonique, il s’agit de prospection directe soumise à consentement au titre de l’Art. 398 PKE et du § 7(2) UWG (la loi allemande contre la concurrence déloyale), même entre professionnels. Cela relève de la responsabilité de l’agence ; les Conditions d’utilisation l’y obligent en conséquence.
Destinataires	L’agence et toute personne à qui elle remet le lien.
Pays tiers	Aucun.
Conservation	Le rapport et le résultat de la vérification expirent après 90 jours et sont alors supprimés par le traitement nocturne (fe_reports_aufraeumen()) ; l’entrée de vérification est supprimée après 90 jours lors du traitement collectif quotidien à partir de 04:00 (srv/cron_status.php). Avec l’espace de travail, immédiatement.
MTO	Section 8. Quota mensuel (paramètre, valeur par défaut 30) ; la même page dans un délai de sept jours renvoie le même rapport ; l’opt-out s’applique.

B.9 Outil d’en-têtes sans compte

Champ	Mention
Finalité	Note gratuite (A+ à F) pour les en-têtes de sécurité de la page d’accueil d’un domaine. Deux requêtes, aucun navigateur, aucun formulaire, aucune soumission.
Catégories de personnes concernées	Personnes qui utilisent l’outil ; exploitants du domaine vérifié.
Catégories de données à caractère personnel	Journal des requêtes comme en B.4 (source « headers », adresse IP, hachage de session, hôte). Résultat : hôte, note, points, en-têtes évalués (header_checks).
Base juridique	Art. 6(1)(f) RGPD, comme en B.4 et B.5.
Destinataires	Google (reCAPTCHA, B.23).
Pays tiers	États-Unis via reCAPTCHA.
Conservation	Journal des requêtes 7 jours ; résultats après actuellement 90 jours (traitement de suppression nocturne, partie « header_checks », paramètre « headers_keep_days »). Pour les domaines d’un compte, la note est recalculée chaque jour et enregistrée avec le domaine.
MTO	Section 8. Limites par adresse IP et par jour ; l’opt-out s’applique.

B.10 Comptes clients

Champ	Mention
Finalité	Gestion des comptes clients, des espaces de travail et des formules.
Catégories de personnes concernées	Clients (professionnels) et membres de leurs équipes disposant de leur propre compte.
Catégories de données à caractère personnel	Adresse e-mail et forme normalisée, mot de passe uniquement sous forme de hachage, prénom (obligatoire), nom et entreprise (si indiqués) ; l’application n’enregistre pas l’adresse ni le numéro de TVA, ceux-ci ne sont fournis qu’à Stripe (B.26) ; statut, langue, mode d’affichage, devise, formule et état de facturation, identifiant client et d’abonnement Stripe, fin de la période de facturation, résiliation à la fin de la période, identifiants de confirmation et de réinitialisation avec expiration, nouvelle adresse e-mail jusqu’à sa confirmation, heure de l’inscription, de la dernière connexion et dernière adresse IP, heure de révocation de toutes les sessions, données du second facteur (B.11), rapport mensuel activé/désactivé, heure de l’e-mail de rappel, déblocages via des codes, code de recommandation et recommandation (users). Espaces de travail avec nom, heures, statut (workspaces) ; appartenance avec rôle et date d’adhésion (workspace_users).
Source	Inscription et paramètres définis par la personne ; état de facturation transmis par Stripe.
Base juridique	Art. 6(1)(b) RGPD (contrat). Dernière adresse IP : (f) (sécurité du compte).
Destinataires	Stripe (B.26) ; fournisseur de services de messagerie pour les e-mails relatifs au compte (B.25). Les membres d’un même espace de travail voient le nom, l’adresse e-mail et le rôle des autres membres.
Pays tiers	Via Stripe et le fournisseur de services de messagerie.
Conservation	Jusqu’à la suppression par le titulaire du compte. Lors de la suppression, les propres espaces de travail du titulaire que personne d’autre n’utilise disparaissent avec tous les domaines et leurs données ; les espaces de travail comptant d’autres membres reviennent à un autre membre, d’abord aux administrateurs, et parmi eux au plus ancien. Les appartenances, jetons de maintien de connexion, appareils, clés API, codes Telegram en attente, retours sur les rapports (B.35) et la ligne du compte sont supprimés ; un abonnement payant en cours est d’abord résilié immédiatement chez Stripe, sans remboursement (www/ajax.php, fe_konto_reste_loeschen()). Une résiliation dans l’espace de facturation prend en revanche effet à la fin de la période ; ensuite, le compte continue avec la formule gratuite. Ce qui subsiste est exposé à la section 6.4. Les comptes jamais confirmés et auxquels personne ne s’est jamais connecté sont supprimés après 30 jours, sauf si un autre membre est rattaché à leur espace de travail (traitement de suppression nocturne, partie « pending_accounts »). Il n’y a pas de suppression des comptes inactifs. Si le contrat relatif au compte prend fin d’une autre manière, par exemple par notre résiliation, nous supprimons le compte au plus tard 30 jours après la fin du contrat ; cela se fait actuellement manuellement (engagement pris dans le Contrat de sous-traitance).
MTO	Section 8.

B.11 Connexion, appareils, second facteur et journal d’activité

Champ	Mention
Finalité	Protection des comptes : limitation des tentatives de connexion et autres tentatives de mot de passe, affichage et révocation des appareils connectés, connexion à deux facteurs, traçabilité des modifications.
Catégories de personnes concernées	Titulaires de compte et membres des équipes ; personnes qui tentent une connexion, une inscription ou le mot de passe d’un portail client.
Catégories de données à caractère personnel	Tentatives de connexion : adresse IP, adresse e-mail saisie, réussite, heure (login_attempts). Appareils : hachage de l’identifiant de session (jamais l’identifiant lui-même), lien vers le jeton de maintien de connexion, adresse IP, identifiant du navigateur ainsi que le navigateur, le système d’exploitation et le type d’appareil qui en sont déduits, heures de connexion, de dernière activité et de révocation, et pour « Voir en tant que client » l’identifiant de la personne de l’assistance (login_sessions). Jetons de maintien de connexion pour « Rester connecté » : sélecteur, vérificateur, expiration (remember_tokens). Second facteur : secret chiffré, heure d’activation, dernier pas de temps utilisé, codes de récupération uniquement sous forme de hachage (dans users). Journal d’activité : compte, espace de travail, action, cible, détails, adresse IP, pays, heure (audit_logs). Compteurs de tentatives pour la connexion, le second facteur, la confirmation du mot de passe, la réinitialisation du mot de passe, l’inscription et les mots de passe des portails clients : une clé HMAC dérivée de la finalité et de l’identifiant du compte (pour une adresse inconnue ou pour une réinitialisation, l’adresse e-mail en minuscules), de l’adresse IP, du compte et de l’adresse IP ensemble, ou de l’identifiant du portail (également avec l’adresse IP), nombre de tentatives, expiration ; les adresses e-mail et IP n’y sont pas enregistrées en clair (table auth_attempt_buckets).
Base juridique	Art. 6(1)(b) RGPD en liaison avec l’Art. 32 (liste des appareils, second facteur) et (f) (tentatives de connexion, journal d’activité). Intérêt : protéger les comptes contre la prise de contrôle, documenter les modifications (Art. 5(2)). Mise en balance : une adresse tronquée ne permet pas de répondre à la question « était-ce moi ? » ; le journal d’activité doit survivre à un litige qui ne survient que des mois plus tard.
Destinataires	Aucun. Le titulaire du compte voit ses appareils et reçoit les tentatives de connexion, appareils et activités dans l’export de données ; pendant une session « Voir en tant que client », ni l’adresse IP ni le navigateur de la personne de l’assistance n’y apparaissent.
Pays tiers	Aucun.
Conservation	Tentatives de connexion 7 jours ; après une connexion réussie, les tentatives échouées depuis la même adresse sont immédiatement supprimées. Compteurs de tentatives à la fin de leur fenêtre de temps (actuellement 15 minutes, une heure pour la réinitialisation du mot de passe et l’inscription) ; ceux qui ont expiré sont supprimés lors de l’accès suivant et par le traitement nocturne. Appareils 90 jours après la dernière utilisation ou après la révocation (traitement de suppression nocturne, partie « sessions »), immédiatement avec le compte. Les jetons de maintien de connexion expirent après 30 jours. Journal d’activité 365 jours (chaque nuit) ; lorsqu’un compte est supprimé, ses entrées subsistent jusqu’à la fin de la durée de conservation (section 6.4).
MTO	Section 8.

B.12 Preuve de la conclusion du contrat

Champ	Mention
Finalité	Prouver quelle version des Conditions d’utilisation, du Contrat de sous-traitance et de la Politique de confidentialité un Client a acceptée ou dont il a pris connaissance lors de l’inscription, et que le Client utilise le service pour son activité professionnelle.
Catégories de personnes concernées	Clients.
Catégories de données à caractère personnel	Par document : compte, document, version (hachage du texte affiché), occasion, adresse IP, identifiant du navigateur, heure (legal_consents). La version affichée elle-même avec le texte intégral, la langue, le titre et l’adresse, une fois par version (legal_versions ; ne contient aucune donnée à caractère personnel).
Base juridique	Art. 6(1)(b) et (f) RGPD (preuve de la conclusion du contrat, défense contre des prétentions).
Destinataires	Aucun. Le titulaire du compte reçoit ses enregistrements dans l’export de données.
Pays tiers	Aucun.
Conservation	Aussi longtemps que le compte existe ; après la suppression du compte, quatre ans à compter du consentement, puis suppression nocturne (srv/cron_status.php). Justification dans le code : délai de prescription de trois ans à compter de la fin de l’année, arrondi au chiffre supérieur. La question de savoir si le droit polonais suggère une autre durée fait partie de l’examen juridique.
MTO	Section 8. Si l’un des trois documents manque, l’inscription est fermée.

B.13 Invitations d’équipe

Champ	Mention
Finalité	Inviter d’autres personnes dans un espace de travail.
Catégories de personnes concernées	Personnes invitées.
Catégories de données à caractère personnel	Adresse e-mail, rôle, identifiant d’invitation, personne invitante, expiration, heure d’acceptation (workspace_invites) ; l’e-mail d’invitation dans la boîte d’envoi (B.25).
Source	Saisies par le membre invitant.
Base juridique	Art. 6(1)(b) RGPD à l’égard du Client ; à l’égard de la personne invitée, (f) (intérêt du Client à associer son équipe).
Destinataires	Fournisseur de services de messagerie (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
Pays tiers	Via le fournisseur de services de messagerie.
Conservation	Une invitation est valable 14 jours et uniquement tant que la personne invitante est propriétaire ou administrateur de l’espace de travail. Invitations non acceptées après leur expiration, invitations acceptées 30 jours après l’acceptation (chaque nuit, srv/cron_status.php et partie « invites » dans cfg/fristen_lib.php). Avec l’espace de travail, immédiatement.
MTO	Section 8.

B.14 « Voir en tant que Client » par le support

Champ	Mention
Finalité	Un super-administrateur voit l’application telle qu’un Client la voit, afin de résoudre une demande d’assistance (« le bouton n’apparaît pas chez moi »).
Catégories de personnes concernées	Le Client concerné ; le super-administrateur.
Catégories de données à caractère personnel	Tout ce que le Client voit dans l’application. Sont journalisés : une ligne d’appareil distincte portant l’identifiant du super-administrateur (login_sessions), le début et la fin dans le journal d’activité (audit_logs).
Base juridique	Art. 6(1)(b) RGPD (assistance dans le cadre du service), à titre subsidiaire (f).
Limites	Une heure au maximum, puis déconnexion complète. La fin de la vue déconnecte également complètement le super-administrateur, y compris la session dont il provenait ; il ne revient dans l’espace d’administration qu’en se reconnectant avec son mot de passe et son second facteur. La vue prend fin immédiatement si le super-administrateur est rétrogradé ou bloqué. Tout ce qui modifie le compte du Client est bloqué : mot de passe, adresse e-mail, second facteur, appareils, abonnement, export, suppression, transfert. L’espace d’administration est fermé pendant la session. Le Client voit l’accès dans sa liste d’appareils et dans l’export de données en tant qu’accès du support.
Destinataires	Aucun.
Pays tiers	Aucun.
Durée de conservation	Ligne d’appareil 90 jours, journal d’activité 365 jours.
MTO	Section 8.

B.15 Domaines, preuve de contrôle et surveillance

Champ	Mention
Finalité	Le service principal pour les Clients : conserver des domaines dans le compte, apporter la preuve de contrôle, vérifier régulièrement et détecter les modifications. Cela comprend le pouls du formulaire (une requête légère sans navigateur toutes les 10 à 30 minutes selon l’offre), la surveillance quotidienne du DNS de messagerie et des certificats, la date d’expiration du domaine, les listes de blocage, les fichiers exposés, les versions visibles de l’extérieur, l’inventaire des scripts, les modifications visuelles du formulaire, les pannes des fournisseurs de CAPTCHA et de messagerie, ainsi que la veille des vulnérabilités des plugins de formulaire.
Catégories de personnes concernées	Les Clients et les membres de leur équipe ; les exploitants des domaines, lorsqu’il s’agit de personnes physiques.
Catégories de données à caractère personnel	Domaine avec hôte, identifiant public, note, libellé client, type et identifiant de la preuve, fréquence de vérification, surveillance activée/désactivée, fenêtres de maintenance, valeur d’une demande, identifiants pour le badge, le contrôle de livraison et le hook de déploiement, clé du plugin, états et derniers résultats des surveillances (DNS, certificat, authenticité de l’e-mail du formulaire, listes de blocage, fichiers exposés, en-têtes, versions) (domains). Pouls par page de formulaire (form_pulse). Vulnérabilités issues des versions de plugins (vuln_hits). Inventaire des scripts avec adresse, hachage, taille, approbation avec la personne ayant approuvé et le motif (script_inventory, script_changes). Vérifications comme en A.4. Pour les fichiers exposés, le chemin, la gravité et le type sont enregistrés, jamais le contenu.
Requêtes adressées à des tiers	Requêtes DNS (SPF, DMARC, MX, enregistrement de preuve). Consultation du registre via RDAP selon l’annuaire de l’IANA : uniquement le nom de domaine. Listes de blocage DNS (SpamCop, PSBL, Mailspike, SURBL ; Spamhaus uniquement avec des identifiants d’accès enregistrés, actuellement non) : adresses IP du serveur web et du serveur de messagerie et nom de domaine, aucune donnée de visiteurs. Google Web Risk uniquement s’il est configuré (actuellement non) : l’adresse de la page d’accueil. Autorité d’horodatage : uniquement une valeur de hachage (B.19). WPVulnerability : uniquement l’identifiant d’un plugin ou d’un thème, ou la version de WordPress ; nous effectuons nous-mêmes la comparaison avec la version du plugin installée. Pages de statut de Cloudflare, hCaptcha, Google Cloud, SendGrid, Mailgun et Brevo : rien n’est transmis hormis la requête elle-même.
Source	Le Client ; requêtes adressées à la page du Client ; annuaires publics.
Base juridique	Art. 6(1)(b) RGPD.
Destinataires	Les services cités ne reçoivent aucune donnée à caractère personnel de nos Clients, dans la mesure où les noms de domaine et les adresses de serveur d’une entreprise ne sont pas des données à caractère personnel ; pour les entrepreneurs individuels, le nom de domaine peut constituer une donnée à caractère personnel. Les membres de l’espace de travail voient le domaine.
Pays tiers	Les requêtes peuvent atteindre des services situés dans des pays tiers (par exemple consultations de registre, listes de blocage). Seul ce qui est indiqué à la ligne « Requêtes adressées à des tiers » est transmis.
Durée de conservation	Jusqu’à la suppression du domaine. fe_domain_loeschen() supprime alors immédiatement les résultats de vérification, formulaires, constats, images, rapports, tâches, destinataires d’alertes et journal des alertes, incidents, codes Telegram, livraisons, pouls, vulnérabilités et preuves ; via les clés étrangères, les formulaires surveillés, exécutions de navigateur, compte de test et compteurs de formulaires ; les données de plugin de l’hôte si aucun autre domaine n’y fait référence. Sont également supprimés l’inventaire des scripts et les modifications de scripts du domaine ; ils n’ont pas de durée de conservation propre (section 6.4). Résultats de vérification au maximum 13 mois, le dernier est conservé.
MTO	Section 8. Surveillance des fichiers exposés et des versions uniquement pour les domaines vérifiés, au maximum une requête par chemin, uniquement les 8 premiers Ko ; sonder sans demande les chemins de tiers ferait de l’outil un instrument d’attaque.

B.16 Alertes, incidents et escalade vers le titulaire du compte

Champ	Mention
Finalité	Informer le Client des dysfonctionnements et des modifications, respecter les fenêtres de maintenance, prendre en compte et escalader les incidents. Lorsque les destinataires sont des tiers, nous agissons pour le compte du Client (A.3) ; lorsqu’il s’agit du titulaire du compte lui-même, le traitement est décrit ici.
Catégories de personnes concernées	Titulaires de compte et membres de l’équipe en tant que destinataires.
Catégories de données à caractère personnel	Comme en A.3. Les notifications s’affichent dans la langue du titulaire du compte.
Base juridique	Art. 6(1)(b) RGPD.
Destinataires	Prestataire de messagerie ; services de chat choisis (4.1).
Pays tiers	Selon le canal (4.1).
Durée de conservation	Comme en A.3 : journal de livraison 90 jours, notifications récapitulatives 30 jours après la livraison, incidents jusqu’à leur résolution puis 180 jours. Destinataires d’alertes avec le domaine.
MTO	Section 8.

B.17 Rapport mensuel aux comptes

Champ	Mention
Finalité	Le 1er de chaque mois à partir de 08:00 (rattrapage jusqu’au 3), un e-mail par compte couvrant tous ses domaines : niveau, score et évolution, alertes, bots bloqués, envoi d’e-mails, valeur de comparaison.
Catégories de personnes concernées	Titulaires de compte actifs ayant activé le rapport mensuel.
Catégories de données à caractère personnel	Adresse e-mail, langue, chiffres clés des domaines.
Base juridique	Art. 6(1)(b) RGPD (partie du service). Désabonnement possible dans les paramètres ; peut être désactivé de manière centralisée.
Destinataires	Prestataire de messagerie (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
Pays tiers	Via le prestataire de messagerie.
Durée de conservation	Pas de stockage distinct ; l’e-mail reste dans la file d’envoi pendant 30 jours (B.25).
MTO	Section 8.

B.18 Badge et page de confirmation publique

Champ	Mention
Finalité	Un Client peut intégrer une image de badge sur son site web et la relier à une page de confirmation publique. Le badge n’affiche « Protégé » que si le domaine est vérifié, que la surveillance est active et que la dernière vérification achevée date d’au plus 45 jours et a abouti à « Protégé » ou « Partiellement protégé » ; sinon, il affiche de manière neutre « Vérification du formulaire de contact ». La page de confirmation indique le niveau et la date, sans aucun constat individuel.
Catégories de personnes concernées	Les visiteurs du site web du Client dont le navigateur charge l’image ; les visiteurs de la page de confirmation.
Catégories de données à caractère personnel	Lors du chargement de l’image : adresse IP, heure, adresse demandée, page de provenance et identifiant du navigateur dans le journal du serveur web (B.1). L’adresse de l’image n’ouvre aucune session, ne dépose aucun cookie et n’écrit rien dans le journal des pages vues. La page de confirmation est une page normale (B.2, B.3).
Base juridique	Art. 6(1)(f) RGPD. Intérêt : fournir l’image et assurer la sécurité de l’exploitation. La question de savoir si le Client et nous sommes responsables conjoints du traitement pour la transmission de l’adresse IP du visiteur, au sens de la jurisprudence relative aux contenus de tiers intégrés, et si un accord au titre de l’art. 26 est nécessaire, reste ouverte pour l’examen juridique. Le Client reçoit une proposition de texte pour sa politique de confidentialité.
Destinataires	Aucun.
Pays tiers	Aucun.
Durée de conservation	14 jours (journal du serveur web). L’image est mise en cache pendant une heure. Lorsque le badge est désactivé, l’identifiant cesse d’être valide.
MTO	Section 8.

B.19 Journal de preuve et horodatage

Champ	Mention
Finalité	Un journal par domaine et par mois (offres payantes) : ce qui a été vérifié, avec quel résultat, ce qui a été signalé et ce qui a changé, à titre de preuve pour la responsabilité (accountability), les assureurs ou les audits fournisseurs. Chaque version reçoit un numéro de vérification ; une page publique confirme le domaine, la période et les chiffres clés, sans détails. Depuis le 7 octobre 2026, une autorité d’horodatage conforme à la RFC 3161 confirme l’heure.
Catégories de personnes concernées	Les Clients ; indirectement, les personnes susceptibles d’être nommées dans le journal en tant qu’approbateurs ou personnes ayant pris connaissance.
Catégories de données à caractère personnel	Domaine, mois, numéro de vérification, hachage du contenu (SHA-512), résumé et données du journal, réponse d’horodatage, autorité d’horodatage et heure, tentatives échouées (proof_docs).
Base juridique	Art. 6(1)(b) RGPD.
Destinataires	L’autorité d’horodatage (par défaut Certum, en secours DigiCert) reçoit uniquement le hachage du journal, pas son contenu. Public : chiffres clés via la page de confirmation. Le Client et toute personne à qui le Client remet le journal ou le numéro de vérification.
Pays tiers	Aucun transfert de données à caractère personnel : un hachage ne permet aucune déduction quant au contenu. L’autorité de secours est établie aux États-Unis.
Durée de conservation	Jusqu’à la suppression du domaine (fe_domain_loeschen()). L’horodatage n’est pas un horodatage électronique qualifié au sens d’eIDAS.
MTO	Section 8.

B.20 Plugin et extension : vérification, connexion et transmission

Champ	Mention
Finalité	Le plugin WordPress et l’extension TYPO3 peuvent demander une vérification (même sans compte), se connecter à un compte (l’installation vaut preuve de contrôle en un clic dans le compte), débloquer des fonctions de protection, transmettre des chiffres chaque jour (A.9) et signaler immédiatement les erreurs d’e-mail et le mode maintenance.
Catégories de personnes concernées	Les Clients ; les exploitants de sites web qui utilisent le plugin sans compte.
Catégories de données à caractère personnel	Par hôte : version du plugin et du CMS, nombre de vérifications, identifiant du dernier rapport, hachage du secret de connexion, premier et dernier contact (plugin_sites). Codes de connexion à usage unique sous forme de hachage avec date d’expiration (plugin_connect_tokens). Codes de déploiement d’une agence sous forme de hachage avec préfixe, libellé, utilisations, personne les ayant créés (workspace_connect_codes). Journal des requêtes avec l’adresse IP du serveur appelant (B.4). La clé du plugin est visible publiquement dans l’en-tête (head) du site web ; il s’agit d’un hachage du secret, et le secret lui-même n’est enregistré que sous forme de hachage et n’est jamais renvoyé.
Base juridique	Art. 6(1)(b) RGPD (compte) ; sans compte (f) (vérification demandée, prévention des abus).
Destinataires	Aucun.
Pays tiers	Aucun.
Durée de conservation	Les données d’un hôte sont supprimées dès qu’aucun domaine n’y fait plus référence ; la ligne d’un plugin sans compte seulement après 90 jours sans contact (passe de suppression nocturne, partie « orphan_hosts »). Codes à usage unique un jour après leur expiration. Codes de déploiement avec l’espace de travail.
MTO	Section 8. Depuis le 27 septembre 2026, le serveur n’accepte que des paires de clés liées au site web ; les anciens secrets de connexion non liés ont été supprimés.

B.21 Protection en essaim

Champ	Mention
Finalité	Défense commune contre le spam : les sites web connectés signalent les domaines des liens contenus dans les messages que leur couche de protection a arrêtés. Un domaine qui apparaît sur au moins trois sites web avec au moins cinq occurrences en sept jours est inscrit sur une liste renvoyée à tous les sites web connectés ; leur couche de protection place les messages contenant de tels liens en quarantaine, sans jamais les faire disparaître.
Catégories de personnes concernées	Les titulaires des domaines de liens signalés, lorsqu’il s’agit de personnes physiques (par exemple l’exploitant d’un site de spam sous son propre nom). Pas les expéditeurs ni les destinataires des messages : les adresses, textes et noms ne sont pas signalés.
Catégories de données à caractère personnel	Signaux : type, domaine, hôte déclarant, jour, occurrences (swarm_signals). Liste : type, domaine, nombre de sites web et d’occurrences, horodatages (swarm_list). Les grands services, les domaines de nos Clients et les exceptions définies par l’exploitant ne sont jamais inscrits.
Réseaux IP	Le partage de réseaux IP (/24, /48) a été préparé. Il est désactivé et le plugin n’en signale aucun ; il ne sera activé qu’après un examen juridique, car les adresses IP sont des données à caractère personnel.
Base juridique	Art. 6(1)(f) RGPD. Intérêt : protéger les formulaires de tous les Clients contre les vagues de spam. Mise en balance : uniquement des domaines, seuils minimaux contre l’empoisonnement, aucune perte de messages, retrait possible à tout moment.
Destinataires	Tous les sites web connectés (la liste des domaines).
Pays tiers	Selon la localisation des sites web connectés ; la liste peut aussi atteindre des sites web situés hors de l’EEE. Elle ne constitue des données à caractère personnel que dans des cas limites (domaines de personnes physiques). La base de transfert au titre du chapitre V du RGPD pour ces cas reste à déterminer (question ouverte pour l’examen juridique).
Durée de conservation	Signaux 30 jours (passe quotidienne de l’essaim à partir de 04:00, cfg/swarm_lib.php). La liste est recalculée chaque jour ; ce qui n’atteint plus le seuil en sort.
MTO	Section 8.

B.22 Clés API, interface de programmation et serveur MCP

Champ	Mention
Finalité	Accès des propres outils du Client (API REST, Zapier, Make, serveur MCP pour assistants IA) aux domaines, vérifications et incidents du Client.
Catégories de personnes concernées	Les Clients qui créent des clés.
Catégories de données à caractère personnel	Clé uniquement sous forme de hachage, préfixe, libellé, dates de création, de dernière utilisation et de révocation (api_keys). Appels par minute (api_usage).
Base juridique	Art. 6(1)(b) RGPD.
Destinataires	L’outil que le Client dote de la clé ; c’est le Client qui le détermine.
Pays tiers	Selon l’outil du Client.
Durée de conservation	Clés jusqu’à leur révocation, immédiatement avec le compte ; clés sans compte (données héritées) la nuit. Compteurs d’appels après un jour (nettoyés occasionnellement lors d’un appel).
MTO	Section 8.

B.23 reCAPTCHA et notre propre protection des formulaires

Champ	Mention
Finalité	Défense contre les accès automatisés à nos propres formulaires : vérification gratuite, outil d’en-têtes, opt-out, connexion, inscription, mot de passe oublié et réinitialisation, support et contact. En outre, notre propre protection sans tiers : piège (champ caché), contrôle temporel signé et jeton CSRF. Depuis le 29 octobre 2026, également notre protection des formulaires formconfirmed (preuve de travail et jeton de vérification à usage unique) pour la vérification gratuite, l’inscription, la connexion et « mot de passe oublié ».
Catégories de personnes concernées	Les personnes qui soumettent ces formulaires.
Catégories de données à caractère personnel	Chez Google : adresse IP, données du navigateur et de l’appareil, données comportementales, cookies Google. Chez nous : l’évaluation de Google (score et action) uniquement au moment de la vérification, sans enregistrement, pas même lorsqu’une soumission est rejetée. Pour notre propre protection des formulaires : adresse IP (enregistrée uniquement sous forme tronquée et hachée), page, horodatages, champ piège rempli oui/non ; aucun contenu.
Moment	Le script de Google ne se charge que lors de la soumission d’un formulaire protégé, et non à l’ouverture de la page. Notre propre protection des formulaires récupère sa tâche à l’ouverture de la page et effectue son calcul dès que le formulaire est utilisé. Sur le système de développement, reCAPTCHA est désactivé.
Base juridique	Art. 6(1)(f) RGPD. Intérêt : protection contre les bots, en particulier pour la vérification gratuite, qui pourrait sinon être utilisée contre des sites web de tiers. La question de savoir si l’accès à l’équipement terminal requiert un consentement au titre du § 25 TDDDG ou de l’Art. 399 PKE, bien que le script ne se charge qu’à la soumission, reste ouverte pour l’examen juridique. Notre propre protection des formulaires ne dépose aucun cookie, n’enregistre rien dans le navigateur et ne crée aucune empreinte ; elle a vocation à remplacer reCAPTCHA à terme.
Destinataires	Google Ireland Limited ; Google LLC. Aucun pour notre propre protection des formulaires.
Pays tiers	États-Unis (uniquement reCAPTCHA). Base : certification au titre du cadre de protection des données UE-États-Unis (EU-US Data Privacy Framework) ou clauses contractuelles types ; à documenter en détail.
Durée de conservation	reCAPTCHA : aucun stockage chez nous ; chez Google selon ses règles. Notre propre protection des formulaires : identifiant haché 1 heure, jetons de vérification utilisés 11 minutes au maximum, résultats de vérification sans adresse IP 30 jours.
Panne	Si Google ne répond pas dans les trois secondes ou fournit une réponse inexploitable, la soumission est rejetée ; il en va de même d’un jeton vide et d’une réponse portant sur une action autre que celle du formulaire. La vérification n’est ignorée que lorsque reCAPTCHA est désactivé. Pour notre propre protection des formulaires, une soumission sans jeton de vérification valide est rejetée ; si le service n’était pas joignable pour la tâche, elle est acceptée.
MTO	Section 8.

B.24 Support et formulaire de contact

Champ	Mention
Finalité	Recevoir les demandes via la fenêtre de support et la page de contact et y répondre. Les deux utilisent la même route et la même table.
Catégories de personnes concernées	Les demandeurs, connectés ou non.
Catégories de données à caractère personnel	Compte (si connecté ; c’est alors l’adresse du compte qui s’applique, et non celle saisie), adresse e-mail, motif choisi dans une liste fixe, texte jusqu’à 4,000 caractères, statut, adresse IP complète, pays, identifiant du navigateur, page de provenance (chemins propres uniquement), langue, dates de réception et de réponse (support_requests) ; entrée dans le journal d’activité (sans le texte) ; accusé de réception au demandeur dans la file d’envoi (B.25), avec le texte jusqu’à 2,000 caractères uniquement pour les expéditeurs connectés, sans le texte pour les demandes faites sans connexion.
Base juridique	Art. 6(1)(b) RGPD lorsque la demande concerne un contrat ; sinon (f). Adresse IP complète : (f) (limite de trois demandes par heure et par adresse, prévention des abus).
Destinataires	Prestataire de messagerie (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA) pour l’accusé de réception et la réponse. Telegram reçoit un signal fixe sans aucune variable (« il y a une nouvelle demande de support ») et donc aucune donnée à caractère personnel.
Pays tiers	Via le prestataire de messagerie.
Durée de conservation	24 mois (passe de suppression nocturne, partie « support ») ; plus tôt manuellement. En cas de suppression d’un compte, les demandes sont conservées jusqu’à la fin de la durée de conservation (section 6.4).
MTO	Section 8. reCAPTCHA, notre propre protection des formulaires, limitation du débit.

B.25 Envoi d’e-mails (file d’envoi)

Champ	Mention
Finalité	E-mails transactionnels : confirmation de l’inscription et des nouvelles adresses e-mail, réinitialisation du mot de passe, invitations, alertes, rapports mensuels, confirmations et rapports du portail, accusés de réception et réponses du support, rappels concernant la période d’essai et la configuration, notifications opérationnelles aux exploitants. Aucune publicité, aucun e-mail à des personnes qui ne se sont pas inscrites elles-mêmes ou n’ont pas été désignées comme destinataires par le Client.
Catégories de personnes concernées	Les destinataires de ces e-mails.
Catégories de données à caractère personnel	Adresse du destinataire, objet, contenu complet, adresse de réponse, finalité, voie d’envoi, statut, erreur, tentatives, horodatages (mail_outbox). Le contenu peut inclure des liens de confirmation et de réinitialisation comportant des identifiants valides.
Base juridique	Art. 6(1)(b) RGPD ; pour les notifications opérationnelles (f).
Destinataires	Namecheap, Inc. (Private Email), Phoenix, Arizona, USA (envoi) ; le titulaire du compte voit ses e-mails envoyés dans l’export de données (sans le contenu).
Pays tiers	Selon le lieu de traitement du prestataire de messagerie ; le contrat et la base de transfert restent à documenter (section 4).
Durée de conservation	30 jours (la nuit, srv/cron_status.php). Cette durée est délibérément la plus courte des journaux : un long journal d’envoi constituerait une collection de clés valides. La passe de statut vérifie toutes les cinq minutes si une nouvelle tentative est due.
Statut	L’envoi d’e-mails doit être configuré avant le lancement. Tant que le prestataire de messagerie, avec son siège et sa base juridique, n’est pas arrêté, les textes juridiques affichent un repère.
MTO	Section 8. Les e-mails en échec sont renvoyés à intervalles croissants et abandonnés après un nombre maximal de tentatives.

B.26 Paiements et facturation

Champ	Mention
Finalité	Conclusion et gestion des abonnements (mensuels ou annuels, payables d’avance), période d’essai de 14 jours sans carte avec un rappel trois jours avant la fin, paiement sur facture pour les abonnements annuels (désactivé par défaut), déblocages via des codes d’hébergeurs et de partenaires sans paiement, facturation, conservation à des fins fiscales.
Catégories de personnes concernées	Les Clients.
Catégories de données à caractère personnel	Chez Stripe : adresse e-mail, nom, adresse de facturation, numéro de TVA, données de paiement, factures ; en tant que métadonnées, notre identifiant de compte et l’offre. Chez nous : identifiant client et identifiant d’abonnement Stripe, offre, statut, fin de période, résiliation en fin de période (users) ; événements Stripe reçus uniquement avec identifiant, type, statut et horodatages, sans contenu (stripe_events) ; utilisations de codes d’hébergeurs avec compte, campagne et date d’expiration (bundle_redemptions). Les données de carte ne nous parviennent jamais.
Source	Le Client dans le processus de paiement de Stripe ; événements provenant de Stripe.
Base juridique	Art. 6(1)(b) RGPD ; pour la conservation à des fins fiscales (c).
Destinataires	Stripe Payments Europe Limited (Irlande) ; Stripe, Inc. (États-Unis). Pour certaines parties du traitement des paiements, Stripe agit sous sa propre responsabilité ; la répartition précise des rôles fait partie de l’examen juridique.
Pays tiers	États-Unis via Stripe, Inc. ; base : Data Privacy Framework ou clauses contractuelles types selon les conditions de Stripe.
Durée de conservation	Champs de facturation avec le compte ; un abonnement en cours est résilié avant la suppression du compte. Factures et pièces de facturation conformément au droit fiscal polonais pendant cinq ans à compter de la fin de l’année au cours de laquelle le délai de paiement de l’impôt a expiré ; elles sont conservées chez Stripe et peuvent être consultées dans le portail client de Stripe. Les événements Stripe et les utilisations de codes n’ont pas de durée de conservation (section 6.4).
MTO	Section 8. Événements Stripe acceptés uniquement avec une signature valide ; chaque événement est traité une seule fois.

B.27 Sauvegardes

Champ	Mention
Finalité	Restauration après une erreur : suppression erronée, migration endommagée.
Catégories de personnes concernées	Toutes les personnes dont les données figurent dans la base de données.
Catégories de données à caractère personnel	Dump complet et compressé de la base de données de l’application. Les captures d’écran et les fichiers de logo sont conservés en dehors de la base de données et ne font pas partie de cette sauvegarde. Les identifiants des comptes de test n’y figurent que sous forme chiffrée (A.5).
Procédure	Chaque nuit à 03:00, après la passe de suppression, afin que la sauvegarde n’emporte pas ce que les durées de conservation viennent de supprimer. Le dump n’est conservé qu’après vérification de son contenu (code de sortie, nombre de tables, dernière ligne). Le dimanche, un test de restauration charge la dernière sauvegarde dans une base de données jetable et la compare table par table. En cas d’échec, un signal et un e-mail sont envoyés aux exploitants.
Base juridique	Art. 6(1)(f) RGPD en liaison avec l’Art. 32(1)(c).
Destinataires	Aucun.
Pays tiers	Aucun.
Durée de conservation	14 jours ; les dumps plus anciens ne sont supprimés qu’après une nouvelle sauvegarde réussie (cfg/backup_lib.php). Les suppressions effectuées pendant cette période n’atteignent la sauvegarde qu’à son expiration ; si des données sont restaurées à partir d’une sauvegarde, les demandes d’effacement sont ensuite appliquées à nouveau.
Emplacement	Les sauvegardes sont actuellement conservées au même emplacement que la base de données et ne sont pas chiffrées séparément ; une copie chiffrée sur un second site est prévue (sections 8.1 et 10).
MTO	Section 8.

B.28 Journal des erreurs et alerte d’erreur

Champ	Mention
Finalité	Détecter et corriger les erreurs avant qu’un Client ne les signale. Les nouveaux types d’erreurs et les vagues d’erreurs sont signalés aux exploitants, avec en outre un aperçu quotidien à partir de 08:00.
Catégories de personnes concernées	Les utilisateurs dont la requête provoque une erreur ; indirectement, les personnes dont les données apparaissent dans un message d’erreur.
Catégories de données à caractère personnel	Niveau, source, message, contexte en JSON, identifiant de compte de la session, heure (error_logs). Types d’erreurs : empreinte, modèle (dont les adresses e-mail, adresses, nombres et identifiants ont été retirés), un exemple de message non modifié de 2,000 caractères au maximum, première et dernière occurrence, nombre (error_kinds).
Base juridique	Art. 6(1)(f) RGPD (sécurité de l’exploitation, Art. 32).
Destinataires	Les exploitants par e-mail via le prestataire de messagerie : pour un nouveau type d’erreur, la source et le texte brut du message jusqu’à 400 caractères (non nettoyé), ainsi que l’e-mail d’aperçu quotidien ; pour une vague d’erreurs, seul le signal Telegram est envoyé. Telegram ne reçoit que des phrases fixes sans variables (« Un nouveau type d’erreur est survenu », « Nombreuses erreurs en peu de temps »).
Pays tiers	Via le prestataire de messagerie.
Durée de conservation	Journal des erreurs 90 jours (la nuit). Types d’erreurs sans durée de conservation (section 10). L’alerte d’erreur est activée sur le système de production et désactivée sur le système de développement.
MTO	Section 8.

B.29 Signaux d’exploitation et surveillance de l’état

Champ	Mention
Finalité	Détecter les pannes : toutes les cinq minutes, une vérification des composants (page d’accueil, base de données, espace disque, signal de vie du scanner, retard de la file d’attente), page de statut, signal en cas de dysfonctionnement et lors du retour à la normale, signal de vie vers un service de surveillance externe afin que même une panne complète soit détectée ; retard en amont du scanner.
Catégories de personnes concernées	En règle générale, aucune.
Catégories de données à caractère personnel	Aucune. Lignes quotidiennes par composant avec le nombre de vérifications et la dernière erreur (system_status_logs), signal de vie du scanner (scanner_heartbeat), chiffres clés quotidiens sans lien avec des personnes (daily_stats). Les signaux envoyés à Telegram sont des phrases fixes sans variables ; le signal de vie est une requête sans contenu.
Base juridique	Sans objet, faute de données à caractère personnel ; à titre de précaution, Art. 6(1)(f).
Destinataires	Telegram (phrases fixes) ; le service de surveillance externe (uniquement la requête) ; les exploitants par e-mail.
Pays tiers	Telegram hors de l’UE ; aucune donnée à caractère personnel n’est transmise.
Durée de conservation	Lignes de statut 400 jours (la nuit).
MTO	Section 8.

B.30 Opt-out – exclure un domaine

Champ	Mention
Finalité	Toute personne peut exclure définitivement n’importe quel domaine des vérifications sans preuve ; le blocage prend effet immédiatement pour toutes les voies de vérification (vérification gratuite, plugin sans compte, étude, vérification de prospects, outil d’en-têtes) et également pour les domaines de Clients payants disposant d’une preuve de contrôle ; leur surveillance en cours prend fin à la prochaine vérification planifiée. Il s’applique au domaine et à sa variante www, et non aux autres sous-domaines. Il n’est levé que par nous, sur demande et sur preuve. Afin que les abus (par exemple un concurrent qui bloque les domaines d’autrui) puissent être détectés et annulés, le blocage est journalisé.
Catégories de personnes concernées	Les personnes qui excluent un domaine.
Catégories de données à caractère personnel	Domaine, motif facultatif jusqu’à 250 caractères, source, adresse IP, pays, identifiant du navigateur, heure ; lors de la levée, heure, personne ayant levé le blocage et motif (blocklist). Journal des requêtes comme en B.4.
Base juridique	Pour l’exclusion, Art. 6(1)(f) RGPD. Intérêt : donner effet, de manière permanente et sur toutes les voies de vérification, à la volonté qu’un domaine ne soit pas vérifié. Lorsque la personne qui exclut est elle-même une personne concernée, l’exclusion donne en même temps effet à son opposition au titre de l’Art. 21 (Art. 6(1)(c)). Pour l’adresse, le pays et l’identifiant du navigateur, (f) (détection des abus).
Destinataires	Google (reCAPTCHA, B.23).
Pays tiers	États-Unis via reCAPTCHA.
Durée de conservation	Adresse IP, pays et identifiant du navigateur après 12 mois (passe de suppression nocturne, partie « optout_ip »). L’exclusion elle-même est conservée de manière permanente, afin de produire ses effets.
MTO	Section 8. De nombreux blocages provenant d’un même pays en peu de temps génèrent une anomalie (B.4).

B.31 Rappel après l’inscription

Champ	Mention
Finalité	Un e-mail unique, deux à 14 jours après l’inscription, aux comptes confirmés sans domaine confirmé : « Ajouter un site web » ou « Confirmer le domaine ». Aucune offre, aucun prix, aucune montée en gamme ; avec la mention qu’il ne sera pas renvoyé. Jours ouvrés de 09:00 à 18:00, au maximum 50 par passe.
Catégories de personnes concernées	Les nouveaux titulaires de compte.
Catégories de données à caractère personnel	Adresse e-mail, langue, heure d’envoi (champ « rappel envoyé » dans users), domaine et statut de confirmation.
Base juridique	Art. 6(1)(b) RGPD (indication relative à la configuration de son propre compte). La question de savoir si l’e-mail constitue une communication relative à la relation contractuelle ou une information commerciale nécessitant un consentement (Art. 10 UŚUDE, ustawa o świadczeniu usług drogą elektroniczną (loi polonaise sur la fourniture de services par voie électronique) ; Art. 398 PKE ; § 7 UWG) reste ouverte pour l’examen juridique ; l’exploitant peut le désactiver de manière centralisée.
Destinataires	Prestataire de messagerie (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
Pays tiers	Via le prestataire de messagerie.
Durée de conservation	L’heure est conservée aussi longtemps que le compte ; l’e-mail 30 jours dans la file d’envoi.
MTO	Section 8. L’heure est enregistrée avant l’envoi, afin qu’une interruption ne déclenche pas un second e-mail.

B.32 Bot Telegram pour les alertes des Clients

Champ	Mention
Finalité	Un chat Telegram est associé en tant que destinataire d’alertes : le Client reçoit un lien vers notre bot avec un code à usage unique ; lorsque le destinataire appuie sur « Démarrer », notre serveur lit le code dans les nouveaux messages adressés au bot et enregistre l’identifiant du chat. Aucun point de terminaison ouvert de notre côté (webhook) n’est nécessaire pour cela.
Catégories de personnes concernées	Les Clients et les personnes dont le chat Telegram est associé.
Catégories de données à caractère personnel	Code à usage unique, domaine, compte créateur, événements, mode de livraison, identifiant du chat, horodatages (telegram_links) ; l’identifiant du chat en tant que destinataire (alerts). Telegram fournit d’autres informations de profil avec le message ; seuls le code et l’identifiant du chat sont exploités et enregistrés.
Base juridique	Art. 6(1)(b) RGPD ; pour les tiers en tant que destinataires, A.3.
Destinataires	Telegram.
Pays tiers	Hors de l’UE, pas de décision d’adéquation ; le choix est fait par le Client (4.1). La base et l’information sont des questions ouvertes pour l’examen juridique.
Durée de conservation	Un code est valable 30 minutes ; les lignes d’association sont supprimées après un jour lors de la création d’un nouveau code, les codes non utilisés avec le compte et le domaine. L’identifiant du chat en tant que destinataire jusqu’à la suppression du destinataire d’alertes ou du domaine.
MTO	Section 8.

B.33 Programme partenaires et codes de déblocage

Champ	Mention
Finalité	Un compte peut recommander de nouveaux Clients au moyen d’un code de parrainage et reçoit une commission sur leurs factures payées pendant un nombre limité de mois. Le code est transmis dans l’adresse jusqu’à l’inscription ; aucun cookie n’est déposé. Les hébergeurs et les partenaires peuvent émettre des codes qui débloquent une offre pour une durée déterminée sans paiement ; une semaine avant la fin, le Client reçoit un rappel.
Statut	Le programme partenaires est désactivé par défaut tant que les Conditions partenaires ne sont pas en place.
Catégories de personnes concernées	Les partenaires et les Clients recommandés.
Catégories de données à caractère personnel	Code de parrainage, partenaire recommandant et date de la recommandation (dans users) ; commission avec partenaire, Client, identifiant de facture Stripe, montant, devise, commission, statut, horodatages (partner_commissions). Déblocage avec offre, fin, source, rappel (dans users) ; campagnes et utilisations (bundle_campaigns, bundle_redemptions).
Base juridique	Art. 6(1)(b) RGPD (accord de partenariat) ; pour le Client (f) (règlement de la commission, sans transmettre au partenaire les données du Client au-delà du montant de la commission) ; registres fiscaux (c).
Destinataires	Le partenaire voit ses commissions.
Pays tiers	Aucun.
Durée de conservation	Parrainage et déblocage avec le compte. Les commissions et les utilisations n’ont pas de durée de conservation dans le code ; en tant que pièces comptables, les commissions sont soumises à la conservation à des fins fiscales (section 6.4).
MTO	Section 8.

B.34 Point de signalement des vulnérabilités

Champ	Mention
Finalité	Recevoir les signalements de vulnérabilités dans formexposed, selon les règles de la page Sécurité et de /.well-known/security.txt.
Catégories de personnes concernées	Les auteurs de signalements ; les personnes dont les données figurent dans un signalement à titre de preuve.
Catégories de données à caractère personnel	Adresse e-mail, nom, contenu du signalement et pièces jointes, tels que l’auteur du signalement les envoie. Le signalement nous parvient par e-mail à l’adresse qui y est indiquée ; l’application ne l’enregistre pas.
Base juridique	Art. 6(1)(f) RGPD (sécurité du service, Art. 32) ; lorsqu’un signalement contient des données à caractère personnel de tiers à titre de preuve, également (f), dans le but de corriger la vulnérabilité.
Destinataires	Prestataire de messagerie et, jusqu’à la mise en place de la boîte aux lettres, la redirection de domaine chez Namecheap (section 4).
Pays tiers	Via le prestataire de messagerie et, jusqu’à la bascule, la redirection.
Durée de conservation	Aucune durée de conservation n’est fixée ni appliquée techniquement (section 10). L’exploitant doit encore fixer la durée ; une approche évidente consisterait à supprimer les preuves de tiers une fois la vulnérabilité corrigée et à traiter la correspondance comme les demandes de support.
MTO	Section 8.

B.35 Retour sur un rapport

Champ	Mention
Finalité	Recevoir des retours sous un rapport (« Quelque chose ne va pas dans ce rapport ? ») afin de détecter les erreurs de reconnaissance des formulaires. Le super-administrateur les classe (nouveau, confirmé, corrigé, rejeté) et peut télécharger les données de vérification du rapport en tant que cas de test (formulaires avec champs, motifs et constats, sans captures d’écran et sans textes envoyés activement).
Catégories de personnes concernées	Les personnes qui consultent un rapport, connectées ou non.
Catégories de données à caractère personnel	Catégorie et vérification issues de listes fixes, adresse de la page jusqu’à 500 caractères, texte jusqu’à 1,000 caractères, langue, heure, identifiant du rapport, vérification, hôte ; identifiant de compte si connecté ; HMAC-SHA256 de l’adresse IP avec une clé secrète pour la limite ; statut, personne en charge, date de traitement (report_feedback). Journal d’activité : changements de statut et téléchargements d’un cas de test. Aucune adresse e-mail, aucune adresse IP en clair.
Base juridique	Art. 6(1)(f) RGPD (détection et correction des erreurs de reconnaissance ; limite contre les abus).
Destinataires	Aucun.
Pays tiers	Aucun.
Durée de conservation	24 mois (passe de suppression nocturne, partie « report_feedback ») ; la somme de contrôle de l’adresse IP est effacée après 2 jours (partie « report_feedback_ip ») ; immédiatement en cas de suppression d’un compte. Les cas de test téléchargés ne contiennent aucune donnée sur la personne ayant fait le retour.
MTO	Section 8. Notre propre protection des formulaires (piège, heure signée, CSRF), au maximum 5 retours par heure et 20 par jour par somme de contrôle, 10 par rapport ; lisibles uniquement par les super-administrateurs.

6. Conservation – ce que couvre la passe de suppression nocturne et ce qu’elle ne couvre pas

Il existe une suppression automatique, et elle a un emplacement précis. Une passe de statut (srv/cron_status.php) est lancée toutes les cinq minutes via la crontab du serveur web, sur le système de production comme sur le système de développement. Elle vérifie les composants, récupère le courrier du contrôle de livraison, planifie les vérifications et envoie les alertes. Une fois par jour, dans la plage de 03:00 à 03:04, elle supprime les données selon les durées de conservation, puis crée la sauvegarde. Depuis le 27 septembre 2026, elle appelle en outre la passe de conservation de cfg/fristen_lib.php (fe_fristen_lauf()), dont les parties s’exécutent indépendamment les unes des autres : si l’une échoue, les autres continuent, et l’erreur est consignée dans le journal des erreurs.

Preuve que la passe s’exécute : l’état des sauvegardes du système de développement indique une sauvegarde réussie à 03:00 le 11 octobre 2026 ; la sauvegarde est créée dans le même bloc immédiatement après la suppression. La passe n’écrit un journal par table supprimée que sur la sortie standard, que la crontab ignore ; il n’existe aucune trace permanente de ce qui a été supprimé et quand (section 10).

Les durées de conservation qui apparaissent sous forme d’espaces réservés sont définies dans l’espace d’administration, dans les paramètres de conservation. La passe lit les mêmes paramètres ; les textes indiquent donc toujours la durée au terme de laquelle les données sont effectivement supprimées.

6.1 Couvert par la passe quotidienne

Données	Durée de conservation et déclencheur	Emplacement dans le code
Journal des pages vues (access_logs)	60 jours	srv/cron_status.php
Journal d’activité (audit_logs)	365 jours	srv/cron_status.php
Journal des erreurs (error_logs)	90 jours	srv/cron_status.php
File d’envoi (mail_outbox)	30 jours	srv/cron_status.php
Jetons « Rester connecté » (remember_tokens)	après expiration (30 jours)	srv/cron_status.php
Invitations non acceptées (workspace_invites)	après expiration (14 jours)	srv/cron_status.php
Tentatives de connexion (login_attempts) ; compteurs de tentatives (auth_attempt_buckets)	7 jours ; compteurs à l’expiration de leur fenêtre temporelle (actuellement 15 minutes, une heure pour la réinitialisation du mot de passe et l’inscription), également lors de l’accès suivant	srv/cron_status.php
Journal des requêtes des vérifications sans compte (check_throttle)	7 jours	srv/cron_status.php
Codes à usage unique pour la connexion du plugin (plugin_connect_tokens)	1 jour après expiration	srv/cron_status.php
Anomalies résolues (abuse_flags)	90 jours après résolution	srv/cron_status.php
Rapports expirés avec résultat de vérification, formulaires, constats, images et tâche (uniquement sans domaine dans un compte)	anonymes 30 jours, prospects 90 jours	fe_reports_aufraeumen()
Journal de livraison des alertes (alert_log)	90 jours	fe_alert_log_aufraeumen()
Lignes de statut (system_status_logs)	400 jours	srv/cron_status.php
Preuves de consentement des comptes supprimés (legal_consents)	dès que le compte a été supprimé et que le consentement date de 4 ans	srv/cron_status.php
Orphelins de domaines supprimés : résultats de vérification, tâches, données d’alerte, incidents, codes Telegram, livraisons, pouls, vulnérabilités, preuves, inventaire des scripts et modifications de scripts	immédiatement lors de la passe suivante	fe_fristen_lauf(), parties « orphan_scans », « orphan_rows »
Données de plugin des hôtes sans domaine ; ligne de plugin sans compte	immédiatement ; ligne après 90 jours sans contact	partie « orphan_hosts »
Résultats de l’outil d’en-têtes (header_checks)	actuellement 90 jours	partie « header_checks »
Résultats de vérification d’un domaine avec formulaires, constats, images, rapports, tâches	13 mois ; le dernier achevé par domaine est conservé	partie « old_scans »
Exécutions de navigateur, tâches de navigateur terminées, séries temporelles (form_browser_runs, scan_jobs, form_performance)	13 mois	parties « browser_runs », « browser_jobs », « form_performance »
Compteurs de formulaires (form_metrics), chiffres quotidiens du plugin et notifications de modification (plugin_stats, plugin_changes)	13 mois	parties « form_metrics », « plugin_stats »
Appareils connectés (login_sessions)	90 jours après la dernière utilisation ou la révocation	partie « sessions »
Invitations acceptées	30 jours après acceptation	partie « invites »
Demandes de support (support_requests)	24 mois	partie « support »
Retours sur les rapports (report_feedback)	24 mois ; somme de contrôle de l’adresse IP 2 jours	parties « report_feedback » et « report_feedback_ip »
Versions PDF des rapports en cache (var/pdf)	7 jours	partie « pdf_cache »
Adresse IP, pays et identifiant du navigateur dans l’opt-out (blocklist)	12 mois ; l’exclusion est conservée	partie « optout_ip »
Abonnés aux portails (client_subscribers)	non confirmés 30 jours ; désabonnés 3 ans	partie « subscribers »
Comptes jamais confirmés, avec l’espace de travail	30 jours sans connexion, sauf si un autre membre y est rattaché	partie « pending_accounts »
Clés API sans compte (données héritées)	immédiatement	partie « api_keys »

6.2 En dehors de la plage de 03:00

Données	Durée de conservation et déclencheur	Emplacement dans le code
Copies dans la boîte de contrôle du contrôle de livraison	après traitement, toutes les cinq minutes	fe_zustellung_abholen()
Correspondances du contrôle de livraison (delivery_log)	180 jours, à chaque récupération	fe_zustellung_abholen()
Données chiffrées du compte de test dans les tâches (scan_jobs)	après l’exécution, au plus tard après une heure	serveur d’analyse ; fe_login_aufraeumen()
Incidents (alert_incidents) avec leurs tentatives de livraison d’escalade	tant qu’ils ne sont pas résolus ; 180 jours après résolution	fe_vorfaelle_aufraeumen() dans cfg/vorfall_lib.php
Notifications récapitulatives envoyées (alert_queue)	30 jours après livraison	cfg/kanal_lib.php
Signaux de l’essaim (swarm_signals)	30 jours, chaque jour à partir de 04:00	cfg/swarm_lib.php
Vérifications de prospects (prospect_checks)	90 jours, chaque jour à partir de 04:00	srv/cron_status.php
Codes d’association Telegram (telegram_links)	1 jour, lors de la création d’un nouveau code	cfg/kanal_lib.php
Compteurs d’appels API (api_usage)	1 jour, occasionnellement lors d’un appel	cfg/agentur_lib.php
Pannes de fournisseurs résolues (provider_incidents), cache des vulnérabilités (vuln_cache)	respectivement 90 et 30 jours ; aucune donnée à caractère personnel	cfg/anbieter_lib.php, cfg/luecken_lib.php
Données brutes des études	à la publication	fe_studie_veroeffentlichen()
Sauvegardes	14 jours, après une nouvelle sauvegarde réussie	cfg/backup_lib.php
Journaux du serveur web	14 jours	rotation des journaux du système

6.3 Lors d’une suppression par le Client

• Suppression d’un domaine (fe_domain_loeschen()) : résultats de vérification avec formulaires, constats et fichiers image, rapports, tâches, destinataires d’alertes, journal de livraison, file des récapitulatifs, incidents, codes Telegram, livraisons, pouls, vulnérabilités, journaux de preuve, le domaine dans les portails clients à sélection fixe ; via les clés étrangères, les formulaires surveillés avec exécutions de navigateur, observations et séries temporelles, compte de test, compteurs de formulaires ; les données de plugin de l’hôte si aucun autre domaine n’y fait référence. L’inventaire des scripts et les modifications de scripts du domaine sont également supprimés avec lui ; ils n’ont pas de durée de conservation propre (sections 6.4 et 10). Les données restées sans domaine associé de la période antérieure au 27 septembre 2026 sont effacées par la passe nocturne (parties « orphan_scans », « orphan_rows »).
• Suppression d’un espace de travail (fe_arbeitsbereich_daten_loeschen()) : en outre, la marque y compris le logo, les portails clients y compris les abonnés, les codes de déploiement, les vérifications de prospects ; ainsi que les invitations et les adhésions.
• Suppression d’un compte : mettre fin immédiatement chez Stripe à un abonnement payant en cours, sans remboursement ; transférer ou supprimer les espaces de travail propres du titulaire ; supprimer les adhésions, les jetons « Rester connecté », les appareils, les clés API avec leurs compteurs, les codes Telegram ouverts et la ligne du compte.
• Suppression d’un compte de test (fe_login_loeschen()) : écraser les données chiffrées, supprimer la ligne, vider les tâches en attente.

6.4 Ce que la passe ne couvre pas

Cette liste est la plus importante. Elle nomme les données pour lesquelles il n’existe aucune durée de conservation automatique ou qui survivent à une suppression.

Données	Ce qui s’applique	Appréciation
Données du compte y compris la dernière adresse IP (users)	jusqu’à la suppression par le titulaire du compte ; pas de suppression des comptes inactifs	données contractuelles ; une règle pour les comptes inactifs de façon permanente sans abonnement fait défaut
Journal d’activité, pages vues, journal des erreurs d’un compte supprimé	sont conservés avec l’identifiant de compte et l’adresse IP jusqu’à la fin de leur durée de conservation	voulu (preuve des actions même après la résiliation) ; l’identifiant ne renvoie plus à aucun compte
Demandes de support d’un compte supprimé	sont conservées jusqu’à 24 mois avec l’ancien identifiant de compte	voulu ; l’identifiant n’est pas effacé
Preuves de consentement d’un compte supprimé	jusqu’à ce que le consentement date de 4 ans (à compter du consentement, et non de la suppression du compte)	voulu (section B.12)
Anomalies non résolues avec adresse IP (abuse_flags)	jusqu’à ce que quelqu’un les résolve	point ouvert (section 10)
Types d’erreurs avec exemple de message non modifié (error_kinds)	aucune durée de conservation	point ouvert (section 10)
Inventaire des scripts et modifications de scripts (script_inventory, script_changes)	pas de durée de conservation propre ; conservés tant que le domaine existe et supprimés avec lui	point ouvert (section 10)
Abonnés des portails clients révoqués	jusqu’à la suppression de l’espace de travail	point ouvert (section 10)
Clés API et codes de déploiement révoqués	jusqu’à la suppression du compte ou de l’espace de travail	uniquement hachages, préfixe et libellé ; mineur
Liste des hôtes des études (study_domains), études jamais publiées	aucune durée de conservation	point ouvert (section 10)
Vérifications internes sans domaine ni rapport (résultats de vérification, formulaires, constats, captures d’écran)	aucune durée de conservation ; aucune voie de suppression ne les couvre	point ouvert (section 10)
Commissions, utilisations de codes, événements Stripe	aucune durée de conservation	pertinence comptable ; durée à fixer selon le droit fiscal
Âge du domaine en cache (domain_age_cache)	aucune durée de conservation	uniquement le nom de domaine et la date d’enregistrement
Résultat d’authentification de l’e-mail du formulaire avec le domaine de l’expéditeur	avec le domaine ; écrasé à chaque réception	voir A.1
Exclusions dans l’opt-out	permanentes	voulu ; sans permanence, aucune exclusion ne produit d’effet
E-mails dans la boîte aux lettres du point de signalement et dans la boîte aux lettres générale	aucune durée de conservation technique	point ouvert (section 10)

6.5 En dehors de la base de données

• Les captures d’écran sont conservées sous forme de fichiers en dehors du répertoire web et sont supprimées avec leur résultat de vérification (toutes les voies de suppression ci-dessus suppriment également les fichiers).
• Les fichiers de logo de la marque sont supprimés lors de leur remplacement et avec l’espace de travail.
• Sur le serveur d’analyse, un répertoire temporaire contenant le résultat et les images est créé pour chaque tâche ; il est supprimé après chaque exécution, même en cas d’erreur.
• Les sauvegardes sont conservées sur le serveur web (B.27).
• Les journaux du serveur web contenant l’adresse IP complète sont conservés 14 jours (B.1).

7. Décisions automatisées, profilage et évaluation

formexposed évalue des sites web, pas des personnes. Selon notre appréciation, le service ne prend aucune décision produisant des effets juridiques à l’égard d’une personne ou l’affectant de manière significative de façon similaire (Art. 22(1) RGPD). Il existe toutefois des évaluations automatisées et des blocages automatiques. Nous les énumérons afin que leur qualification puisse être vérifiée.

Mécanisme	Ce qu’il fait	Qui est concerné
Score et verdict d’une vérification	Somme pondérée des couches de protection manquantes (CAPTCHA, piège, jeton, contrôle temporel, CAPTCHA inefficace, configuration exposée connue), de 0 à 100 ; il en résulte « Exposé », « Partiellement protégé » ou « Protégé ». Le verdict du site web suit le plus mauvais formulaire de contact reconnu comme tel par les règles (et non par le modèle de langage) ; sans formulaire de contact, il n’y a pas de verdict. Les pondérations peuvent être définies dans l’espace d’administration.	Les exploitants de sites web ; pour les entrepreneurs individuels, indirectement une personne. Le verdict n’a aucune conséquence juridique ; il s’agit d’un constat accompagné de preuves et d’instructions.
Classification du type de formulaire	D’abord les règles, un modèle de langage local uniquement si les règles renvoient « inconnu ». Détermine si une soumission de test active est autorisée (uniquement pour un formulaire de contact reconnu de manière fiable par les règles). Les formulaires classés par le modèle de langage ne sont jamais soumis et ne comptent pas dans le score et le verdict.	Le Client et les destinataires de ses e-mails de formulaire ; effet protecteur : en cas de doute, rien n’est soumis.
Badge	N’affiche « Protégé » que dans des conditions fixes (B.18), sinon neutre.	Le Client ; aucun effet sur les visiteurs.
Limites et blocages pour la vérification gratuite, l’outil d’en-têtes et l’opt-out	Rejettent les requêtes si les limites par adresse, session, domaine ou système sont atteintes, si le domaine est trop récent ou d’âge inconnu, ou s’il figure sur la liste de blocage.	Les demandeurs ; effet : un service gratuit est refusé pendant quelques heures à quelques jours. Un administrateur peut débloquer une adresse ; les demandes via la page de contact parviennent à un humain.
Anomalies	Des schémas (nombreux domaines depuis une même adresse, rafales de requêtes, nombreux rejets, nombreux opt-outs depuis un même pays, limite quotidienne atteinte) sont enregistrés et signalés. Ils ne bloquent pas par eux-mêmes ; les blocages résultent des limites.	Les demandeurs.
Verrouillage de connexion	Après actuellement huit connexions échouées depuis une même adresse en 15 minutes, les connexions depuis cette adresse sont temporairement rejetées. En outre, toutes les tentatives de connexion, y compris celles réussies, sont comptées par compte et par adresse IP (actuellement huit), par compte toutes adresses confondues (nettement plus, contre les tentatives distribuées) et par adresse IP (actuellement 80) en 15 minutes, de même que les codes de second facteur (dix par compte en 15 minutes) ; au-delà, les tentatives sont rejetées. Des tentatives échouées depuis une autre adresse ne bloquent donc plus le propriétaire de son compte. Les confirmations de mot de passe (cinq par compte en 15 minutes), les e-mails de réinitialisation (trois par adresse et par heure, avec une réponse inchangée), les inscriptions (dix par adresse IP et par heure) et les tentatives de saisie du mot de passe d’un portail client (dix par portail et par adresse IP, 50 par portail en 15 minutes) sont limités de la même manière.	Les personnes qui se connectent, s’inscrivent ou ouvrent un portail client ; effet limité dans le temps, la réinitialisation du mot de passe reste possible.
Seuil reCAPTCHA	Rejette les soumissions dont le score Google est inférieur au seuil ; seuil par point d’utilisation (actuellement 0.7 pour la vérification et l’opt-out). Les réponses portant sur une autre action et les soumissions pour lesquelles Google ne répond pas dans les trois secondes sont également rejetées.	Les personnes qui soumettent nos formulaires ; effet : une nouvelle tentative ou le passage par la page de contact.
Protection en essaim	Inscrit automatiquement un domaine de lien sur une liste lorsque des seuils minimaux sont atteints ; les couches de protection des sites web connectés placent les messages contenant de tels liens en quarantaine.	Les expéditeurs de messages vers les pages des Clients. Effet : le message est retenu, non supprimé, et peut être libéré par l’exploitant du site web. La décision relative au message est prise par le plugin de l’exploitant sur le site web de celui-ci, et non par nous.
Valeurs de comparaison	« Mieux protégé que X % des sites vérifiés », uniquement à partir de totaux portant sur au moins 20 hôtes.	Les exploitants de sites web ; aucun effet.

Ce qui se rapproche le plus de l’Art. 22 est la couche de protection du plugin sur les pages des Clients, qui retient automatiquement des soumissions. Il s’agit d’un traitement effectué par l’exploitant du site web sur son propre serveur (A.10). Elle ne supprime rien, mais place les messages en quarantaine, et l’exploitant peut libérer n’importe quel message. Aucun profilage des visiteurs n’a lieu, ni là ni chez nous ; il n’existe aucun identifiant de visiteur reliant un message à un autre.

8. Mesures techniques et organisationnelles (Art. 32) – description générale

Cette section constitue la description générale au sens de l’Art. 30(1)(g) et (2)(d) RGPD. La version détaillée figure sur la page Mesures techniques et organisationnelles. Chaque mesure ci-dessous est attestée dans le code ou dans la configuration. Les mesures qui n’ont pas encore été mises en œuvre figurent dans la même section (8.1), afin que la description soit complète.

Domaine	Mesure en vigueur
Chiffrement du transport	HTTPS pour le site web, l’application et les interfaces ; HSTS ; cookies de session et de jeton « Rester connecté » uniquement via HTTPS, HttpOnly, SameSite=Lax.
Contrôle d’accès (authentification)	Mots de passe uniquement sous forme de hachage, les nouveaux d’au moins dix caractères et d’au plus 72 octets ; verrouillage de connexion après des tentatives échouées répétées et limites de tentatives par compte et adresse IP combinés, par compte et par adresse IP, de sorte que des tentatives échouées depuis une autre adresse ne bloquent pas le propriétaire ; limites de tentatives également pour les confirmations de mot de passe, la réinitialisation du mot de passe (avec la même réponse et le même temps de réponse), les inscriptions et les mots de passe de portail ; connexion à deux facteurs (TOTP) avec secret chiffré, protection contre la réutilisation des codes et codes de récupération hachés ; nouvel identifiant de session à chaque connexion, les identifiants non émis par le serveur ne sont pas acceptés ; « Rester connecté » non disponible pour les super-administrateurs, chaque jeton n’est valable qu’une seule fois ; la modification de l’adresse e-mail invalide un lien de réinitialisation en cours ; les appareils peuvent être révoqués individuellement ou tous à la fois ; la liste des appareils ne contient que le hachage de l’identifiant de session.
Contrôle d’accès (autorisation)	Rôles par espace de travail (propriétaire, administrateur, lecteur) ; les autorisations sont vérifiées par rapport à l’objet, jamais par rapport à un identifiant provenant du formulaire ; compte de test, « Fix it for me » et vérifications actives réservés aux propriétaires et administrateurs ; « Voir en tant que Client » limité dans le temps et bloqué pour les actions modifiant le compte, sa fin entraîne une déconnexion complète, retour dans l’espace d’administration uniquement avec mot de passe et second facteur ; invitations valables uniquement tant que la personne qui invite est propriétaire ou administrateur ; adresses des webhooks et des canaux de chat affichées aux lecteurs uniquement réduites à l’hôte ; le nom d’hôte d’un domaine vérifié ne peut pas être modifié.
Sécurité de l’application	Jetons CSRF ; requêtes de base de données préparées ; notre propre protection des formulaires (piège, contrôle temporel signé) ; reCAPTCHA sur les formulaires publics ; limitation du débit pour le support, les vérifications et les interfaces ; un seul appel « Fix it for me » à la fois par espace de travail, afin que le quota soit respecté même en cas de requêtes simultanées ; Content Security Policy avec protection contre l’intégration en cadre, qui n’autorise l’exécution que des scripts portant l’autorisation (nonce) de la réponse concernée ; adresse IP issue des en-têtes transférés uniquement depuis notre propre proxy et uniquement à partir de l’entrée qu’il a ajoutée ; jetons d’accès masqués dans le journal des pages vues.
Secrets	Clés API, codes de déploiement, secrets de connexion du plugin, codes à usage unique et mots de passe de portail uniquement sous forme de hachage ; identifiants des comptes de test chiffrés de manière asymétrique, clé privée uniquement sur le serveur d’analyse ; webhooks signés ; événements Stripe uniquement avec une signature valide.
Minimisation des données	Le contrôle de livraison n’enregistre aucun contenu ni aucune adresse d’expéditeur complète ; adresses des destinataires dans les formulaires uniquement sous forme de domaine ; les identifiants de compte dans les adresses de scripts sont remplacés ; chiffres du plugin uniquement à partir de listes fixes ; textes d’erreur d’envoi d’e-mails uniquement sous forme de catégorie ; signaux Telegram sans variables ; images des vérifications par navigateur avec saisies masquées ; aucune capture d’écran derrière une connexion.
Isolation du scanner	Chaque vérification dans son propre conteneur : toutes les capacités Linux retirées, aucune élévation de privilèges, système de fichiers en lecture seule, limites de mémoire et de processus, réseau propre ; contrôle de la cible par rapport aux réseaux privés et locaux avant l’acceptation et dans le scanner, y compris après des redirections ; service workers bloqués, connexions WebSocket fermées. Requêtes du serveur web (preuve de contrôle, outil d’en-têtes, recherche de fichiers, pouls, RDAP, certificats, webhooks et alertes de chat) uniquement sur les ports web usuels et uniquement vers l’adresse exacte vérifiée, webhooks et alertes de chat uniquement via HTTPS.
Stockage	Captures d’écran en dehors du répertoire web, accessibles uniquement via le rapport ; rapports à des adresses aléatoires avec noindex ; répertoire de sauvegarde lisible uniquement par le service.
Disponibilité et restauration	Sauvegarde nocturne avec contrôle du contenu, test de restauration hebdomadaire, alerte en cas d’échec ; vérification des composants toutes les cinq minutes avec signal et e-mail ; signal de vie externe ; arrêt d’urgence pour les vérifications anonymes ; contre-pression en cas d’arriéré.
Traçabilité	Journal d’activité pour les connexions, modifications, suppressions, accès du support et approbations ; journal des erreurs avec alerte.
Suppression	Durées de conservation à un seul endroit du code, issues des mêmes paramètres que les textes (section 6) ; chaînes de suppression pour le domaine, l’espace de travail et le compte, avec les exceptions de la section 6.4.
Droits des personnes concernées	Export en un clic de toutes les données du compte sous forme de fichier, sur la base d’une liste blanche de champs, sans secrets.
Organisation	Espace d’administration réservé aux comptes disposant de droits de super-administrateur, bloqué pendant « Voir en tant que Client » ; systèmes de développement et de production séparés, le système de développement derrière une barrière d’accès supplémentaire ; transfert des textes juridiques après approbation via un outil qui refuse les brouillons et les espaces réservés.

8.1 Mesures non encore mises en œuvre

• Aucun chiffrement de la base de données au repos (mesuré le 11 octobre 2026). Font exception les identifiants des comptes de test et le secret du second facteur, qui sont chiffrés au niveau des champs.
• Connexions internes non chiffrées de bout en bout. Les connexions au sein de notre réseau interne ne sont pas chiffrées de bout en bout. Les identifiants des comptes de test n’y transitent que sous forme chiffrée.
• Aucune sauvegarde sur un second site. Les sauvegardes sont actuellement conservées au même emplacement que la base de données et ne sont pas chiffrées séparément ; une copie chiffrée sur un second site est prévue. D’ici là, elles protègent contre une commande de suppression erronée, et non contre la perte du site.
• Renforcement de l’administration des serveurs non achevé. La sécurité de l’accès administratif à nos serveurs n’atteint pas encore le niveau que nous visons pour l’exploitation ; le renforcement se poursuit. Nous ne publions pas de détails, car ils aideraient un attaquant ; nous les communiquons à une autorité de contrôle sur demande.
• Pas de journal de lecture fonctionnel dans l’espace d’administration. Les actions d’écriture sont consignées dans le journal d’activité ; qui a simplement consulté quelle demande de support ou quel rapport ne peut être déterminé qu’à partir du journal des pages vues (60 jours).
• Pas de journal permanent des suppressions. Ce que la passe nocturne a supprimé n’est pas consigné (section 6).
• Pas de second point de vérification indépendant. La sonde sur un second site n’est pas mise en place (A.6).

9. Délégué à la protection des données – appréciation au titre de l’Art. 37 RGPD

Résultat : selon notre appréciation, il n’existe aucune obligation d’en désigner un. Cette appréciation fait partie de l’examen juridique et sera renouvelée dès que l’une des circonstances énumérées ci-dessous changera.

L’Art. 37(1) impose une désignation dans trois cas.

• Point (a) (autorité publique ou organisme public) ne s’applique pas.
• Point (b) (activités de base exigeant un suivi régulier et systématique à grande échelle des personnes concernées) : notre activité de base est la vérification régulière et systématique de sites web et de formulaires, et non l’observation de personnes. Nous ne créons aucun profil de visiteur, n’utilisons aucun traçage et ne relions aucun message à un autre. Le contrôle de livraison (A.1) fait transiter de véritables messages de visiteurs par notre boîte aux lettres, mais n’exploite que les en-têtes et les 8 premiers Ko pour la correspondance et n’enregistre aucun contenu ; il observe des chemins de livraison, pas des personnes. Les comptes clients et les journaux sont accessoires à l’activité commerciale.
• Point (c) (traitement à grande échelle de catégories particulières au sens de l’Art. 9 ou de données relatives aux infractions au sens de l’Art. 10 en tant qu’activité de base) : non rempli. Des catégories particulières peuvent apparaître incidemment dans les copies d’e-mails de formulaire (A.1), sur des pages derrière une connexion (A.5) ou dans du code collé (A.7) ; une collecte incidente ne constitue pas une activité de base.

L’Art. 37(4) permet au droit national de prévoir d’autres cas. Nous faisons confirmer par un avocat si le droit polonais nous impose d’en désigner un.

Déclencheurs d’une nouvelle appréciation : activation de la protection en essaim avec des réseaux IP ; une fonction qui reconnaît les visiteurs à travers plusieurs messages ou sites web ; l’enregistrement de contenus issus du contrôle de livraison ; un Client dont les formulaires portent principalement sur des catégories particulières (santé, candidatures) avec le contrôle de livraison activé à grande échelle ; le premier salarié ayant accès aux données des clients. Une désignation volontaire reste possible ; les Art. 37 à 39 s’appliquent alors intégralement.

Par ailleurs : la question de savoir si une analyse d’impact relative à la protection des données au titre de l’Art. 35 est requise pour certaines activités de traitement est traitée sur la page Analyse d’impact relative à la protection des données. Son évaluation des seuils conclut qu’une AIPD est requise pour la protection en essaim (B.21) et pour les études à l’échelle envisagée (B.7) et qu’elle est réalisée par nous, et que pour le contrôle de livraison (A.1) elle est requise dans la configuration typique, en tant qu’obligation du Client, que nous accompagnons à cet égard.

10. Points ouverts et mesures prévues

Les points suivants sont attestés dans le code, le schéma ou la configuration, et non supposés. Ils décrivent la situation à la date de la présente version ; la qualification est la nôtre et ne préjuge d’aucune évaluation juridique. Ils sont classés selon leur importance pour les personnes concernées, et non selon la facilité de leur correction. Les mesures prévues et leur priorité sont exposées dans l’Analyse d’impact relative à la protection des données.

Point ouvert	Ce qui est attesté	Portée
Prestataire de messagerie sans contrat documenté	Pour Namecheap, Inc. (Private Email), Phoenix, Arizona, USA, le contrat, les lieux de traitement et la base de transfert ne sont pas documentés. Les e-mails de compte, les alertes et la boîte de contrôle contenant de véritables messages de visiteurs passent par ce prestataire.	Les dispositions pertinentes sont l’Art. 28(2) et (4) et le chapitre V du RGPD. La conclusion et la documentation sont prévues avant le lancement.
Bases juridiques pour les services de chat et reCAPTCHA en suspens	Alertes vers Telegram (pas de décision d’adéquation), Slack, Discord, Microsoft Teams et Google Chat ; reCAPTCHA sans demande de consentement.	Questions ouvertes pour l’examen juridique ; d’ici là, l’information et la base juridique ne sont pas définitives.
La boîte de contrôle peut retenir des messages en cas de perturbation	La suppression a lieu après un traitement réussi ; si la récupération échoue, les copies restent jusqu’à la prochaine passe réussie. Aucun avertissement n’est émis lorsqu’un arriéré s’accumule dans la boîte aux lettres sur une période prolongée.	Les copies contiennent de véritables demandes de visiteurs.
Aucune sauvegarde sur un second site, aucun chiffrement de la base de données au repos	Section 8.1. Une copie chiffrée de la sauvegarde sur un second site est prévue.	Un seul événement sur le site affecterait simultanément les données et la sauvegarde ; un support de stockage volé serait lisible.
Anomalies non résolues sans durée de conservation	Les anomalies ayant pour clé l’adresse IP complète ne sont supprimées que 90 jours après leur résolution ; ce qui n’est jamais résolu est conservé.	Concerne le principe de limitation de la conservation (Art. 5(1)(e)) ; la suppression dépend d’une résolution manuelle. Une durée de conservation fixe est prévue (mesures de l’analyse d’impact relative à la protection des données).
Types d’erreurs avec exemple de message sans durée de conservation	L’exemple de message est enregistré sans modification jusqu’à 2,000 caractères ; le modèle nettoyé retire les adresses et les nombres, l’exemple non.	Les messages d’erreur peuvent contenir des adresses e-mail, des noms d’hôte ou des adresses IP.
Inventaire des scripts sans durée de conservation propre	L’inventaire des scripts et les modifications de scripts sont supprimés avec le domaine (FE_DOMAIN_TABELLEN), y compris lors de la suppression de l’espace de travail ou du compte et lors de la passe nocturne pour les orphelins ; ils n’ont pas de durée de conservation propre. Ils contiennent des adresses de scripts, des adresses de pages et, pour les approbations, la personne ayant approuvé et un motif en texte libre.	Concerne le principe de limitation de la conservation (Art. 5(1)(e)) ; le journal des modifications avec les approbations ne cesse de croître tant que le domaine existe.
Abonnés des portails révoqués	Un portail révoqué est bloqué, non supprimé ; ses abonnés sont conservés jusqu’à la suppression de l’espace de travail.	La finalité (envoi du rapport) a cessé avec la révocation.
Listes des études sans durée de conservation	Après la publication, les hôtes et les segments sont conservés ; les études jamais publiées conservent également leurs données brutes.	La promesse « les données brutes sont supprimées » ne vaut que pour les études publiées.
Vérifications internes sans voie de suppression	Les vérifications de niveau de confiance « interne » qui n’ont ni domaine ni rapport (études et vérifications créées par l’exploitant en ligne de commande) ne sont couvertes par aucune voie de suppression ; avec elles sont conservés les formulaires, constats et captures d’écran de sites web de tiers.	Concerne le principe de limitation de la conservation (Art. 5(1)(e)) ; touche des personnes qui ignorent tout de la vérification. Évalué comme risque élevé dans l’Analyse d’impact relative à la protection des données.
La preuve de contrôle n’est pas renouvelée	La preuve de contrôle est vérifiée une seule fois ; il n’existe dans le code aucune voie par laquelle un domaine la perdrait.	Les soumissions de test actives, la recherche de fichiers et l’analyse derrière la connexion se poursuivent après un changement de propriétaire ou de mandat.
Analyse derrière la connexion : transport vers la page du Client	Comme adresse de connexion, http est autorisé en plus de https, et les erreurs de certificat sur la page du Client n’interrompent pas la connexion.	Les identifiants des comptes de test pourraient être interceptés sur le chemin vers la page du Client.
La suppression dépend d’une plage horaire	Le bloc quotidien ne s’exécute que si une passe de statut démarre entre 03:00 et 03:04. Si cette passe unique échoue (base de données inaccessible, serveur redémarré), la suppression et la sauvegarde de ce jour n’ont pas lieu ; il n’y a pas de rattrapage. Ce qui a été supprimé n’est pas journalisé de manière permanente.	Les durées de conservation sont alors prolongées d’un jour sans que cela se remarque. Une plage manquée ne déclenche aucune alerte ; seule une sauvegarde qui s’exécute et échoue est signalée. La liste de configuration de l’espace d’administration indique la date de la dernière sauvegarde réussie.
Certaines suppressions dépendent de la surveillance	Le vidage de la boîte de contrôle du contrôle de livraison, la suppression des incidents, des notifications récapitulatives envoyées, des signaux de l’essaim et des vérifications de prospects, ainsi que l’effacement des copies résiduelles de comptes de test dans les tâches s’exécutent dans la partie planificateur de la passe de statut, qui ne fonctionne que lorsque la surveillance est activée dans l’espace d’administration ; les correspondances du contrôle de livraison ne sont supprimées que tant qu’une boîte de contrôle est configurée.	Si la surveillance est désactivée de manière centralisée ou si la boîte aux lettres est supprimée, ces durées de conservation cessent de s’appliquer sans que personne ne le remarque.
Point de signalement et boîtes aux lettres sans durée de conservation	Les signalements de vulnérabilités et les autres e-mails entrants sont conservés en dehors de l’application ; aucune durée de conservation n’a été fixée.	Les signalements peuvent contenir des preuves concernant des tiers.
Les valeurs des champs cachés sont lues pendant la vérification	Le scanner lit la valeur des champs de formulaire cachés jusqu’à 24 caractères et des attributs data jusqu’à 60 caractères afin de reconnaître les horodatages et les jetons. Seuls le nom du champ, le type, le libellé et le résultat de la reconnaissance figurent dans la cartographie des champs et les constats, et non la valeur.	Pas de lacune de stockage ; la valeur n’est conservée que dans la mémoire de travail du conteneur d’analyse pendant la vérification. Une valeur pré-remplie (par exemple un numéro de client) est lue au passage, mais pas enregistrée.
Domaine de l’expéditeur déduit dans le résultat d’authentification	A.1.	Pour les domaines personnels des visiteurs, des données à caractère personnel issues d’un véritable message.
Renforcement de l’administration des serveurs non achevé ; connexions internes non chiffrées de bout en bout	Section 8.1. Le renforcement se poursuit ; nous ne donnons pas de détails publiquement.	Un incident de sécurité au niveau des serveurs affecterait simultanément l’application, la base de données et les sauvegardes.
Mesure sur le système de développement	Le schéma, le code et les paramètres ont été mesurés sur le système de développement.	Le code et le schéma correspondent au système de production ; les paramètres peuvent différer et doivent y être vérifiés à nouveau avant le lancement.

11. Tenue du présent registre

L’Art. 30 exige que le registre soit tenu sous une forme écrite et mis à la disposition de l’autorité de contrôle sur demande. Cela suppose une personne qui en est responsable et une périodicité à laquelle il est vérifié par rapport au système plutôt que par rapport à sa version précédente.

• Responsabilité : Lukas Wójcik, propriétaire. Le registre est revu chaque année et à chaque modification d’une activité de traitement.
• Événements nécessitant une mise à jour : un sous-traitant ultérieur nouveau ou modifié, en particulier le choix du prestataire de messagerie ; une nouvelle table ou un nouveau champ contenant des données à caractère personnel ; une modification des durées de conservation ou des chaînes de suppression dans cfg/fristen_lib.php ou srv/cron_status.php ; un nouveau canal d’alerte ou une nouvelle requête adressée à un tiers ; l’activation d’une fonction désactivée par défaut (protection en essaim avec réseaux IP, sonde, domaines propres, programme partenaires, paiement sur facture, Spamhaus ou Google Web Risk) ; un déménagement vers d’autres serveurs.
• Procédure : chaque affirmation figurant ici provient du code, du schéma ou d’une mesure. Une révision qui se contente de lire le texte n’a rien révisé : le schéma et les chaînes de suppression sont mesurés à nouveau, les espaces réservés restent des espaces réservés, les points ouverts sont clos ou reportés avec justification.
• Relation avec les autres documents : le présent registre ne remplace pas la Politique de confidentialité, le Contrat de sous-traitance, les Mesures techniques et organisationnelles ni la liste des Sous-traitants ultérieurs. Lorsque ceux-ci et le présent registre divergent, la divergence constitue un constat.
• Les modifications du présent document sont répertoriées sur la page Modifications des documents contractuels.