Analyse d’impact relative à la protection des données (Art. 35 RGPD)

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

Version 1.0 · Dernière mise à jour : 16 octobre 2026

1. De quoi il s’agit et ce qu’est cette page

Cette page est l’analyse d’impact relative à la protection des données (AIPD) de formexposed au titre de l’Art. 35 RGPD. Elle répond d’abord à la question préalable de savoir si une AIPD est requise – pour chaque opération de traitement séparément, et non pour le service dans son ensemble. Lorsque la réponse est oui, elle procède à l’analyse au titre de l’Art. 35(7)(a) à (d) : une description systématique, la nécessité et la proportionnalité, les risques pour les personnes concernées et les mesures envisagées pour y faire face. Suivent le risque résiduel, la question de la consultation préalable au titre de l’Art. 36 et les règles de réexamen.

L’Art. 35 n’impose pas la publication d’une AIPD. Nous la publions pour deux raisons. Premièrement, les Clients qui utilisent le contrôle de livraison ou l’analyse derrière la connexion ont besoin, pour leur propre analyse, de faits que nous sommes seuls à connaître ; nous leur devons de toute façon ces faits en tant que sous-traitant (Art. 28(3)(f) RGPD). Deuxièmement, notre robot d’exploration vérifie des sites web dont les exploitants ne nous connaissent pas. Ils doivent pouvoir lire quels risques nous voyons pour eux et pour les personnes présentes sur leurs pages, et ce que nous faisons pour y remédier.

Nature juridique. La présente AIPD est une documentation du responsable du traitement au titre de l’Art. 35 RGPD, que nous publions volontairement. Elle ne fait partie d’aucun contrat et ne constitue ni une déclaration, ni une garantie, ni un accord sur la qualité à l’égard des Clients ou de tiers. Les services et garanties que nous devons aux Clients sont régis par les Conditions d’utilisation, le Contrat de sous-traitance et ses annexes ; s’agissant de ces obligations, ils prévalent sur cette page. La page décrit la situation à la date de la présente version. Les cotations de risque et les appréciations 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. Pour les Clients, la page constitue une base pour leur propre analyse, et non un conseil juridique.

Il s’agit de la première version de l’évaluation des seuils. Elle examine, opération de traitement par opération de traitement, si une AIPD est requise, et en consigne le résultat à la section 3.5.

Chaque énoncé de fait obéit au même principe que dans nos autres documents juridiques : mesuré, et non souhaité. Ce qui est attesté dans le code ou dans la base de données est indiqué ici avec sa référence source. Ce qui n’a pas pu être attesté est signalé comme « non vérifié ». Ce qui est simplement prévu est qualifié de « prévu ». Nous nommons ouvertement les points ouverts, accompagnés de la mesure prévue ; une AIPD qui n’énumère que des points forts n’aide pas les personnes qu’elle concerne.

Termes : un exploitant est quiconque gère un site web vérifié. Un Client dispose d’un compte auprès de formexposed. Un visiteur est quiconque utilise le site web d’un Client, par exemple son formulaire de contact. Une référence source désigne un fichier, une fonction ou un paramètre du code source, mesuré par rapport à l’état du système de développement au 11 octobre 2026.

Nous fixons délibérément une limite à la transparence : les points ouverts relatifs à la sécurisation de nos propres serveurs ne sont décrits qu’en termes généraux (R13). Nous nommons le risque et son niveau, mais pas le chemin vers une vulnérabilité précise ; nous communiquerons les détails à une autorité de contrôle sur demande.

2. Rôles : qui porte l’obligation, et pour quoi

L’Art. 35 fait peser l’obligation sur le responsable du traitement. formexposed est responsable du traitement pour certaines opérations de traitement, sous-traitant de ses Clients pour d’autres, et ni l’un ni l’autre pour les données que notre plugin WordPress et notre extension TYPO3 enregistrent sur le site web d’un Client. La réponse à presque toutes les questions du présent document dépend du rôle au regard duquel la question est posée. La répartition suit la Politique de confidentialité et le Contrat de sous-traitance.

Opération de traitement	Rôle de formexposed	Qui porte l’obligation au titre de l’Art. 35
Vérification de sites web de tiers sans instruction de leur exploitant : vérification gratuite, vérification de prospects pour les agences, étude	Responsable du traitement	formexposed
Vérification des domaines du compte Client : surveillance, soumissions de test actives, parcours de navigateur, fichiers exposés, pouls du formulaire	Responsable du traitement pour les données de compte et de vérification du Client ; sous-traitant pour les données à caractère personnel de tiers visibles sur le site web vérifié du Client ; tant qu’un domaine n’est pas vérifié, responsable du traitement comme pour la vérification gratuite	formexposed pour sa propre part ; le Client pour les données de tiers sur son site web
Analyse derrière la connexion avec un compte de test	Sous-traitant : les identifiants et le contenu derrière la connexion appartiennent au site web du Client	Le Client ; formexposed apporte son aide
Contrôle de livraison avec copie de contrôle	Sous-traitant	Le Client ; formexposed apporte son aide
Protection en essaim : liste commune de domaines de liens issus de spam bloqué	Responsable du traitement : nous regroupons les signalements de nombreux sites web, établissons la liste et la diffusons	formexposed
Comptes clients, connexion, journaux, support, envoi d’e-mails, paiements, registres de preuve	Responsable du traitement	formexposed
Portail client et rapport mensuel aux abonnés d’une agence	Sous-traitant	L’agence
Données que le plugin et l’extension enregistrent sur le site web du Client (quarantaine, filet de sécurité, demandes enregistrées)	Ni l’un ni l’autre : les données ne quittent jamais le site web	L’exploitant du site web

Il en découle une distinction que nous énonçons expressément, car elle est souvent mal comprise dans les deux sens. Lorsque formexposed est responsable du traitement, nous réalisons nous-mêmes l’analyse et en assumons le résultat. Lorsque nous sommes sous-traitant, nous ne pouvons pas réaliser l’analyse du Client à sa place, trancher pour lui la question de la nécessité ni consulter l’autorité de contrôle au titre de l’Art. 36 en son nom. Ce que nous pouvons et devons faire, c’est lui fournir tout ce dont il a besoin : la description au titre du point (a), les faits mesurés sur les risques au titre du point (c) et un état honnête des mesures au titre du point (d). Pour le contrôle de livraison et l’analyse derrière la connexion, cette page est exactement cela.

Un Client qui reprend sans modification les sections relatives au contrôle de livraison comme sa propre AIPD n’en a pas réalisé une. Seul le Client peut décider si la copie de contrôle est justifiée pour ses formulaires, si des catégories particulières de données à caractère personnel y sont à prévoir et comment il informe ses visiteurs. La section 11 résume ce qui doit être clarifié à cette fin.

3. Évaluation des seuils : une AIPD est-elle requise ?

3.1 Art. 35(1) et Art. 35(3)

L’Art. 35(1) exige une AIPD lorsqu’un type de traitement, en particulier par le recours à de nouvelles technologies, et compte tenu de la nature, de la portée, du contexte et des finalités du traitement, est susceptible d’engendrer un risque élevé pour les droits et libertés des personnes physiques. L’Art. 35(3) cite trois cas dans lesquels c’est notamment le cas. Aucun des trois ne correspond à formexposed, et cela doit être motivé plutôt qu’affirmé :

Point (a) – l’évaluation systématique et approfondie d’aspects personnels concernant des personnes physiques, fondée sur un traitement automatisé, sur la base de laquelle sont prises des décisions produisant des effets juridiques à l’égard d’une personne physique ou l’affectant de manière significative de façon similaire. Nous évaluons des formulaires et des sites web, pas des aspects personnels de personnes. Le service ne prend aucune décision produisant des effets juridiques à l’égard d’une personne. Ce qui s’en rapproche le plus est la protection en essaim : les messages contenant un lien vers un domaine inscrit sur la liste sont placés en quarantaine sur les sites web connectés. Il s’agit d’une conséquence automatisée pour le message, et non d’une évaluation approfondie d’une personne ; nous la traitons au titre du critère « Évaluation ou notation » à la section 3.3.
Point (b) – le traitement à grande échelle de catégories particulières au sens de l’Art. 9 ou de données relatives aux condamnations pénales et aux infractions au sens de l’Art. 10. Ni prévu ni développé. De telles données peuvent néanmoins nous parvenir par une voie : dans la copie de contrôle de véritables messages de visiteurs lors du contrôle de livraison. Cela dépend du cas d’espèce et ne relève pas de la grande échelle au sens de cette disposition ; c’est toutefois pris en compte dans l’évaluation des risques (R1).
Point (c) – la surveillance systématique à grande échelle d’une zone accessible au public. Cela vise l’observation physique de lieux, et non la consultation de pages web publiques. Invoquer cette disposition comme point d’ancrage pour un robot d’exploration de sites web serait inexact.

La voie correcte est donc l’Art. 35(1) lui-même, appliqué au moyen des neuf critères des lignes directrices du groupe de travail « Article 29 » concernant l’analyse d’impact relative à la protection des données (WP248 rev.01, approuvées par le Comité européen de la protection des données), et la liste de l’autorité de contrôle polonaise au titre de l’Art. 35(4) (section 3.4).

3.2 Les neuf critères des lignes directrices WP248

Les lignes directrices citent neuf caractéristiques qui indiquent un risque élevé probable. En règle générale, une opération de traitement remplissant deux d’entre elles nécessitera dans la plupart des cas une AIPD. Un responsable du traitement peut parvenir à une autre conclusion dans un cas particulier, mais doit alors la motiver et la documenter. À l’inverse, un seul critère peut suffire. Sur cette page, nous utilisons les libellés abrégés suivants :

C1 – Évaluation ou notation, y compris le profilage et la prédiction, par exemple du rendement au travail, de la situation économique, de la fiabilité ou du comportement.
C2 – Prise de décision automatisée avec effet juridique ou effet similaire significatif.
C3 – Surveillance systématique, c’est-à-dire un traitement utilisé pour observer, surveiller ou contrôler les personnes concernées, y compris au moyen de réseaux. Les lignes directrices justifient expressément ce critère par le fait que les personnes concernées ignorent souvent qui collecte leurs données et dans quel but.
C4 – Données sensibles ou données à caractère hautement personnel : catégories particulières au sens des Art. 9 et 10, mais aussi données dont la divulgation affecte significativement la vie quotidienne, y compris les communications électroniques dont la confidentialité doit être protégée.
C5 – Données traitées à grande échelle, mesurées au nombre de personnes concernées, au volume et à l’éventail des données, à la durée et à l’étendue géographique.
C6 – Croisement ou combinaison d’ensembles de données provenant d’opérations de traitement différentes ou de responsables du traitement différents, d’une manière à laquelle les personnes concernées ne s’attendraient pas.
C7 – Données concernant des personnes vulnérables, par exemple des salariés, des enfants, des patients ou d’autres personnes en situation de déséquilibre des pouvoirs.
C8 – Usage innovant ou application de nouvelles solutions technologiques ou organisationnelles ; dans la pratique des autorités de contrôle, le recours à l’intelligence artificielle est régulièrement considéré comme relevant de ce critère.
C9 – Traitement qui empêche les personnes concernées d’exercer un droit ou de bénéficier d’un service ou d’un contrat.

Nous cotons chaque critère comme « rempli », « limite » ou « non rempli » et motivons la cotation à partir du code. Un cas limite ne compte pas comme rempli dans le total, mais est mentionné dans le résultat ; lorsque plusieurs cas limites vont dans le même sens, nous incluons l’opération de traitement dans l’analyse.

3.3 Appréciation par opération de traitement

P1 – Vérification gratuite sans compte (vérification de n’importe quel site web de tiers sur demande)

Toute personne peut saisir un domaine sur la page d’accueil. Le robot d’exploration récupère alors au maximum huit pages publiques de ce site web, lit les formulaires, réalise des captures d’écran et produit un rapport visible par toute personne connaissant son lien aléatoire. L’exploitant du site web n’en apprend rien, sauf s’il remarque l’identifiant du robot dans ses journaux.

C1 – limite. Le rapport évalue la protection d’un formulaire au moyen d’un niveau (« Exposé », « Partiellement protégé », « Protégé ») et d’un score. Pour une société à responsabilité limitée, cela ne concerne pas une personne physique. Pour les entrepreneurs individuels et les indépendants, le domaine peut être attribué à la personne, et le niveau dit alors quelque chose du soin apporté à son activité professionnelle. Ce qui est évalué reste toutefois une configuration technique, et non le comportement ou les caractéristiques d’une personne. Nous traitons ce critère comme limite.
C2 – non rempli. Rien n’est décidé à l’égard de l’exploitant. À l’égard de la personne qui demande la vérification, des limites par adresse IP et par session s’appliquent (cfg/check_lib.php) ; une vérification rejetée n’a pas d’effet significatif.
C3 – non rempli. Il s’agit d’une consultation unique sur demande, au maximum une fois par domaine et par semaine (cfg/check_lib.php, paramètre fc_domain_days = 7). Aucune personne n’est observée. La circonstance invoquée par les lignes directrices pour justifier C3 – les personnes concernées ignorent tout du traitement – est toutefois présente. Elle est prise en compte dans l’évaluation des risques (R5).
C4 – non rempli. Ce qui est enregistré, ce sont la structure du formulaire et les constats, pas les valeurs saisies (scanner/src/crawl.js n’enregistre que la longueur d’une valeur pour les champs visibles). Le scanner lit le début des champs cachés pré-remplis (jusqu’à 24 caractères) et des attributs data (jusqu’à 60 caractères) uniquement pendant la vérification, afin de détecter des jetons et des horodatages ; ils ne sont pas enregistrés. Les captures d’écran peuvent montrer incidemment des personnes et des noms ; le site web d’un cabinet médical affiche sa spécialité dans l’image. Il s’agit d’informations professionnelles publiques, et non de données de santé d’une personne déterminée.
C5 – limite. Le plafond quotidien est de 200 vérifications acceptées (fc_daily_cap), soit arithmétiquement jusqu’à environ 73,000 sites web par an. Seules quelques données à caractère personnel apparaissent par site web, et la durée est courte (30 jours). Mesuré sur le système de développement, le jeu de données contient 2 vérifications anonymes. Non rempli aujourd’hui ; limite compte tenu de la capacité prévue.
C6 – non rempli. Outre la récupération des pages, le service interroge l’âge du domaine via le service RDAP rdap.org (seul le nom de domaine est transmis ; seule la date d’enregistrement est conservée, en cache) et effectue des résolutions DNS. Il s’agit d’informations techniques sur le domaine, et non d’une combinaison d’ensembles de données relatives à des personnes.
C7 – non rempli.
C8 – rempli, sous une forme atténuée. Un navigateur automatisé vérifie les pages, et un modèle de langage sur notre propre serveur classe les formulaires que les règles ne reconnaissent pas (scanner/src/classify.js). Le modèle voit le titre de la page, l’adresse, les libellés des champs et jusqu’à 400 caractères de texte du formulaire. Il ne peut jamais rendre un formulaire « soumissible ».
C9 – non rempli.

Résultat intermédiaire P1 : un critère sous une forme atténuée (C8), deux cas limites (C1, C5). Pas d’obligation selon la règle générale. Comme les deux cas limites vont dans le même sens et que les personnes concernées ignorent tout du traitement, nous incluons P1 dans l’analyse.

P2 – Vérification de prospects pour les agences

Une agence disposant de l’offre Business et ayant configuré sa propre marque peut faire vérifier passivement le site web d’un prospect. Elle reçoit un constat succinct sous sa marque et un rapport détaillé, et transmet elle-même le lien (cfg/akquise_lib.php). Nous ne contactons personne.

C1 – limite, plus marqué que pour P1. Le constat succinct est expressément conçu comme une « porte d’entrée pour le premier entretien ». L’évaluation du site web devient ainsi la base d’une démarche commerciale auprès d’une personne.
C5 – non rempli. Au maximum 30 vérifications par agence et par mois (prospect_monthly), supprimées après 90 jours.
C8 – rempli, sous une forme atténuée (la même technologie que pour P1).
Autres critères – non remplis. Le constat est présenté sous la marque de l’agence, mais n’est pas relié à d’autres données concernant l’exploitant.

Résultat intermédiaire P2 : pas d’obligation selon la règle générale ; inclus pour les mêmes raisons que P1 et parce que la finalité – la prospection de clients – comporte un risque propre (R6).

P3 – Étude « Form Security Index »

Pour une étude, une liste de sites web est vérifiée passivement, avec un débit limité à au plus cinq tâches ouvertes par exécution du processus de statut, qui s’exécute toutes les cinq minutes (cfg/studie_lib.php). Seuls des totaux sont publiés, et des segments uniquement à partir de 20 sites web disposant d’un formulaire (study_min_segment, cfg/studie_lib.php). Les données brutes sont supprimées lors de la publication (cfg/studie_lib.php).

C5 – limite, rempli pour les grandes listes. La taille de la liste n’est pas limitée dans le code ; la limitation de débit permet arithmétiquement plus de mille vérifications par jour. Une étude d’un marché national couvre des milliers de sites web, dont beaucoup sont exploités par des entrepreneurs individuels. À partir d’une telle taille, nous considérons le critère comme rempli.
C8 – rempli, sous une forme atténuée.
C1 – non rempli. Bien que chaque site web soit évalué, seul le total est publié ; l’évaluation ne sert pas à formuler une appréciation sur l’exploitant individuel.
Autres critères – non remplis.

Résultat intermédiaire P3 : pour les études de la taille prévue, deux critères (C5, C8). L’étude atteint donc le seuil ; formexposed réalise l’analyse en tant que responsable du traitement. Mesuré sur le système de développement, aucune étude n’a été créée à ce jour.

P4 – Vérification des domaines du compte Client

Le Client fait vérifier régulièrement les domaines de son compte. Dès qu’il a prouvé qu’il est habilité à contrôler le domaine, s’y ajoutent les soumissions de test actives (au maximum cinq par vérification), la recherche de fichiers exposés et les parcours de navigateur configurés.

C3 – non rempli. La vérification est planifiée et récurrente, mais elle porte sur le propre site web du Client et est effectuée à sa demande, et non pour observer des personnes.
C4 – limite, non. La recherche de fichiers exposés lit au maximum les 8 premiers Ko de chemins tels que /backup.sql ou un journal de débogage afin de déterminer d’après le contenu si le fichier est réellement exposé (cfg/dateien_lib.php). Un tel extrait peut contenir des saisies de formulaire effectuées par des visiteurs. Il n’est examiné qu’en mémoire et n’est jamais enregistré ; ce qui est enregistré, ce sont le chemin, le type et la gravité.
C8 – rempli, sous une forme atténuée.
Autres critères – non remplis.

Résultat intermédiaire P4 : pas d’obligation. Inclus parce que les soumissions de test actives et la vérification des fichiers dépendent d’une preuve qui n’est jamais renouvelée (R7).

P5 – Analyse derrière la connexion

Pour un domaine vérifié, le Client peut enregistrer un compte de test pour son site web. Le scanner se connecte avec ce compte et lit les formulaires sur jusqu’à cinq pages désignées de l’espace membres (cfg/login_lib.php, scanner/src/login.js).

C4 – limite. Les identifiants ne sont pas des données à caractère hautement personnel au sens des lignes directrices, mais leur utilisation abusive ouvre l’accès à l’espace membres. Selon le site web, des contenus confidentiels peuvent se trouver derrière une connexion, par exemple dans un portail membres ou patients. Cela dépend du Client, et non de nous.
C8 – non rempli. Les connexions automatisées sont courantes dans les services de surveillance.
Autres critères – non remplis.

Résultat intermédiaire P5 : pas d’obligation selon la règle générale. Pour les Clients dont l’espace membres affiche des contenus confidentiels, cela peut changer ; la décision leur appartient alors. Inclus en raison des risques de sécurité (R8).

P6 – Contrôle de livraison avec copie de contrôle

Le Client saisit une adresse de contrôle de formexposed en copie cachée dans les paramètres de messagerie de son formulaire. En conséquence, chaque e-mail de formulaire est également envoyé à notre boîte de contrôle – notre message de test comme chaque véritable message d’un visiteur. Une récupération automatisée lit les en-têtes et les 8 premiers Ko, attribue l’e-mail, évalue SPF, DKIM et DMARC, puis le supprime (cfg/zustellung_lib.php).

C4 – rempli. Ce que les visiteurs écrivent dans un formulaire de contact est une communication électronique adressée à une entreprise, au contenu quelconque. Sur le site web d’un cabinet médical, d’un cabinet d’avocats, d’un service de conseil ou d’une école, des données au sens de l’Art. 9 ou concernant des enfants sont à prévoir. Les lignes directrices citent expressément les communications électroniques confidentielles au titre de ce critère.
C3 – limite, plutôt rempli. Chaque message est copié de manière planifiée et continue et évalué automatiquement, sans que l’expéditeur s’en aperçoive. La finalité est de vérifier le chemin de messagerie, et non d’observer des personnes. Toutefois, la circonstance par laquelle les lignes directrices justifient le critère – les personnes concernées ne savent pas qui reçoit leurs données – est pleinement présente tant que le Client n’informe pas ses visiteurs.
C7 – selon le Client. Les patients, les clients de cabinets d’avocats, les candidats à un emploi, les parents et les élèves se trouvent souvent dans une relation de dépendance vis-à-vis du destinataire de leur message.
C5 – limite, non. Pas à grande échelle pour le Client individuel. Chez formexposed, les copies de nombreux Clients convergent dans une seule boîte aux lettres ; cela accroît la gravité d’une violation, et non le nombre par responsable du traitement.
Autres critères – non remplis. L’attribution au domaine et au test n’est pas un croisement d’ensembles de données relatives à des personnes ; la technologie n’est pas nouvelle.

Résultat intermédiaire P6 : C4 rempli, C3 limite et plutôt rempli, C7 rempli pour de nombreux Clients types. Dans la configuration typique, deux critères ou plus sont donc remplis. Une AIPD est requise – en tant qu’obligation du Client, qui est le responsable du traitement. Les sections 6 à 11 lui fournissent les faits nécessaires à cet effet.

P7 – Protection en essaim

Les sites WordPress connectés signalent une fois par jour les domaines des liens issus de messages que leur couche de protection a arrêtés. Un domaine qui apparaît sur au moins trois sites web différents avec au moins cinq occurrences en sept jours est inscrit sur une liste commune ; la liste est renvoyée à tous les sites web connectés, qui placent alors en quarantaine les messages contenant des liens vers ce domaine (cfg/swarm_lib.php).

C6 – rempli. Les signalements de nombreux sites web indépendants les uns des autres, c’est-à-dire de responsables du traitement différents, sont combinés et renvoyés à tous sous forme de liste commune.
C1 – rempli, dans la mesure où un domaine peut être attribué à une personne physique. La liste constitue une classification en tant que source de spam. Les lignes directrices citent la vérification par rapport à une base de données commune de fraude comme exemple de ce critère. La plupart des domaines d’une telle liste appartiennent à des entreprises ou sont des domaines jetables ; le domaine d’un particulier peut toutefois s’y retrouver, à juste titre ou en raison de faux signalements délibérément introduits.
C9 – limite. Un message contenant un lien inscrit sur la liste ne parvient pas immédiatement au destinataire, mais reste dans sa quarantaine jusqu’à ce qu’il le libère. Il n’est pas perdu.
C2 – non rempli. La quarantaine est une conséquence automatisée pour un message, sans effet juridique et avec libération humaine par le destinataire.
Autres critères – non remplis. Les réseaux IP sont désactivés (swarm_ip_enabled = 0, cfg/swarm_lib.php).

Résultat intermédiaire P7 : deux critères (C6, C1) et un cas limite (C9). Le seuil est atteint ; formexposed réalise l’analyse en tant que responsable du traitement. Avec les réseaux IP activés, C1 et C6 seraient remplis sans restriction ; leur activation exige une nouvelle version de la présente analyse (section 12). Mesuré sur le système de développement, il n’existe ni signalements ni entrées dans la liste.

P8 – Comptes clients, connexion, journaux, support, e-mail, paiements

C1 et C9 – non remplis. Un comportement suspect lors de la vérification gratuite entraîne une note avec l’adresse IP (cfg/check_lib.php) et, le cas échéant, le rejet d’autres vérifications. Il s’agit d’une prévention des abus à faible effet, et non d’une évaluation d’aspects personnels.
Autres critères – non remplis. Il s’agit des données habituelles d’un service destiné aux entreprises.

Résultat intermédiaire P8 : aucune AIPD requise. Les opérations de traitement sont décrites dans le Registre des activités de traitement.

P9 – Chiffres du plugin, erreurs de champs, enregistreur, badge, portail client, « Fix it for me »

Le plugin et l’extension transmettent des chiffres quotidiens, l’inventaire des plugins et des catégories d’erreurs, et le plugin WordPress transmet en outre les domaines de liens pour la protection en essaim (activée par défaut) (P7), sans contenus, adresses, noms ni adresses IP de visiteurs ; l’enregistreur conserve des sélecteurs pendant au plus 15 minutes dans le navigateur de l’administrateur. Aucun critère rempli.
Lors de son chargement, le badge transmet les données de connexion habituelles au journal du serveur web, sans cookie. Aucun critère rempli.
Le portail client traite les adresses e-mail des abonnés avec double opt-in pour le compte de l’agence. Aucun critère rempli.
« Fix it for me » fait réécrire le code de formulaire collé par un modèle de langage sur notre propre serveur ; le code n’est pas enregistré. C8 sous une forme atténuée, rien d’autre.

Résultat intermédiaire P9 : aucune AIPD requise.

3.4 La liste de l’autorité de contrôle polonaise au titre de l’Art. 35(4)

L’autorité compétente est le Président de l’Office de protection des données personnelles (Prezes Urzędu Ochrony Danych Osobowych, UODO). Le Président a publié la liste des types d’opérations de traitement nécessitant une AIPD dans la communication du 17 juin 2019 (Komunikat Prezesa Urzędu Ochrony Danych Osobowych z dnia 17 czerwca 2019 r. w sprawie wykazu rodzajów operacji przetwarzania danych osobowych wymagających oceny skutków przetwarzania dla ich ochrony, Monitor Polski 2019, position 666). La liste rattache ses entrées aux critères des lignes directrices WP248, donne des exemples et n’est expressément pas exhaustive ; elle ne remplace pas l’appréciation au titre de l’Art. 35(1).

Selon notre lecture, les types de traitement suivants de la liste correspondent en substance à des opérations de traitement de formexposed :

Type de traitement selon la liste (paraphrasé)	Critère rattaché	Opération de traitement chez formexposed	Appréciation
Comparaison, évaluation ou déduction fondée sur l’analyse de données provenant de différentes sources	C6	P7 Protection en essaim	s’applique
Évaluation ou notation, y compris le profilage	C1	P7 Protection en essaim ; P1 et P2 en tant que cas limites	s’applique à P7
Traitement de catégories particulières de données à caractère personnel	C4	P6 Contrôle de livraison	s’applique selon le Client
Usage innovant ou application de solutions technologiques	C8	P1 à P4 (modèle de langage pour la classification)	s’applique sous une forme atténuée
Traitement à grande échelle	C5	P3 Étude	s’applique aux grandes listes
Surveillance systématique de lieux accessibles au public, y compris avec reconnaissance de caractéristiques	C3	–	ne s’applique pas : ce sont des lieux qui sont visés, pas des sites web

Cette répartition est une lecture, et non une citation ; le libellé des entrées doit être confronté à celle-ci lors de l’examen juridique. Elle confirme le résultat de la section 3.3 sans le modifier. À notre connaissance, l’UODO n’a pas publié de liste au titre de l’Art. 35(5) – opérations de traitement pour lesquelles aucune AIPD n’est requise.

3.5 Résultat de l’évaluation des seuils

Opération de traitement	Rempli	Limite	Résultat
P1 Vérification gratuite	C8 (atténué)	C1, C5	non obligatoire ; incluse
P2 Vérification de prospects	C8 (atténué)	C1	non obligatoire ; incluse
P3 Étude	C8 (atténué), C5 pour les grandes listes	–	requise (obligation de formexposed)
P4 Vérification des domaines des Clients	C8 (atténué)	C4 (vérification des fichiers)	non obligatoire ; incluse
P5 Analyse derrière la connexion	–	C4	non obligatoire ; incluse ; pour le Client selon le contenu
P6 Contrôle de livraison	C4 ; C7 selon le Client	C3 (plutôt rempli), C5	requise (obligation du Client ; cette page apporte son aide au titre de l’Art. 28(3)(f))
P7 Protection en essaim	C6, C1	C9	requise (obligation de formexposed)
P8 Comptes, journaux, support, paiements	–	–	non requise
P9 Chiffres du plugin, badge, portail, « Fix it for me »	C8 (atténué, uniquement « Fix it for me »)	–	non requise

Résultat au regard de l’Art. 35(1) : une AIPD est requise pour certaines opérations de traitement de formexposed. Elle est requise pour la protection en essaim et pour les études de la taille prévue, et formexposed la réalise en tant que responsable du traitement. Pour le contrôle de livraison, elle est requise dans la configuration typique, mais en tant qu’obligation du Client ; formexposed en fournit la base. Pour les autres vérifications de sites web de tiers et de sites propres, elle n’est pas obligatoire. Nous les incluons néanmoins, parce qu’elles utilisent la même technologie, parce que plusieurs cas limites vont dans le même sens et parce que les personnes concernées – exploitants sans compte et personnes présentes sur les pages vérifiées – ignorent tout du traitement. Aucune analyse n’est requise pour les comptes, les journaux, le support et les paiements.

Les sections 6 à 10 s’appliquent donc à P1 à P7. Lorsqu’un énoncé ne s’applique qu’à l’une de ces opérations de traitement, il est signalé comme tel.

4. Délégué à la protection des données : l’appréciation au titre de l’Art. 37

Aucun délégué à la protection des données n’a été désigné. L’Art. 37(1) s’impose au responsable du traitement comme au sous-traitant ; la question est donc la nôtre. Les trois cas prévus par le règlement :

Art. 37(1)	Condition	Résultat
point (a)	Autorité publique ou organisme public	Sans objet ; LW IT Solutions Company Lukas Wójcik est une entreprise individuelle privée.
point (b)	Les activités de base consistent en des opérations de traitement qui exigent un suivi régulier et systématique à grande échelle des personnes concernées	L’activité de base est la vérification et la surveillance de sites web et de formulaires, de manière régulière et systématique. Aucune personne n’est toutefois surveillée : le robot d’exploration n’observe aucun comportement, et le contrôle de livraison n’évalue les e-mails que sous l’angle de la livraison et de l’authenticité. Non rempli.
point (c)	Les activités de base consistent en un traitement à grande échelle de données au sens de l’Art. 9 ou 10	Pas par conception. Des catégories particulières peuvent nous parvenir par la copie de contrôle du contrôle de livraison ; c’est incident, et non une activité de base. Non rempli.

Selon notre appréciation, il n’existe donc aucune obligation d’en désigner un. La question de savoir si le droit polonais impose une désignation allant au-delà au titre de l’Art. 37(4) reste ouverte pour l’examen juridique. Aucun délégué à la protection des données n’ayant été désigné, le conseil prévu à l’Art. 35(2) ne s’applique pas. Si l’examen juridique conclut à une obligation de désignation, le conseil du délégué alors désigné sera demandé avant l’approbation de la présente analyse (section 12). L’interlocuteur pour toute question relative à la présente analyse est le propriétaire, à l’adresse contact@lukaswojcik.com.

5. Méthode, sources et limites de la présente version

Les faits figurant dans le présent document proviennent du code source de l’application et du scanner, du schéma de la base de données, ainsi que des nombres de lignes et des paramètres du système de développement, mesurés le 11 octobre 2026. La base de données et les serveurs ont été consultés en lecture seule. Lorsqu’une mesure contredit une intention – y compris un énoncé de nos propres documents juridiques – nous rapportons la mesure. Nous n’appliquons pas de codes de conduite approuvés au titre de l’Art. 40, dont le respect devrait être pris en compte au titre de l’Art. 35(8).

C’est le système de développement qui a été mesuré. Le service n’a pas encore été lancé. Les chiffres sont donc faibles et en partie des artefacts de test : 112 vérifications, dont 110 sans domaine Client ; 432 captures d’écran ; 2 domaines, dont 1 vérifié ; aucun contrôle de livraison activé ; aucun compte de test enregistré pour l’analyse derrière la connexion ; aucune étude ; aucun signalement dans la protection en essaim. Les mesures doivent être répétées avant le lancement, puis à intervalles réguliers.
N’ont pas été mesurés dans la présente version et doivent être ajoutés avant l’approbation : la configuration du système de production, y compris si et comment la boîte de contrôle y est configurée et si la paire de clés pour l’analyse derrière la connexion y est mise en place ; si le logiciel du modèle de langage journalise les requêtes ; l’état de l’administration des serveurs (R13) ; le contrat avec le prestataire de messagerie.
Il n’a pas été possible de mesurer combien de véritables messages de visiteurs transiteront par la copie de contrôle ni de quels secteurs proviendront les Clients. Ces deux éléments déterminent le poids de R1 et R2 et doivent être établis après le lancement.
Les références sources renvoient à des fichiers et fonctions du code source du système de développement. Ce qui est déterminant, c’est la fonction décrite, et non son emplacement dans le fichier.

Le présent document est un projet. Il n’a pas encore été approuvé par le responsable du traitement (section 12), et deux de ses conclusions – l’appréciation de l’échelle pour P1 et P3 et le poids du contrôle de livraison – dépendent de chiffres qui n’existeront qu’après le lancement.

6. (a) Description systématique des opérations de traitement et des finalités

6.1 Structure du système de vérification

formexposed fonctionne sur ses propres serveurs en Pologne, sans hébergeur externe : un serveur web avec l’application et la base de données, et un serveur d’analyse avec le service de vérification et un modèle de langage local, tous deux dans le même réseau interne. Une vérification se déroule comme suit :

L’application crée une tâche dans la base de données – sous réserve des limites et blocages exposés à la section 6.3.
Le service de vérification sur le serveur d’analyse récupère la tâche, vérifie une seconde fois la liste de blocage, les noms d’hôte et, pour les vérifications anonymes, l’âge du domaine, puis démarre un conteneur isolé pour cette seule tâche : son propre réseau avec ses propres règles de filtrage, aucun privilège particulier, un système de fichiers en lecture seule, des limites de mémoire et de processus, et une limite de temps (scanner/src/worker.js).
Dans le conteneur, un navigateur automatisé récupère au maximum huit pages publiques, d’abord la page d’accueil, puis de préférence les pages de contact, de mentions légales et d’assistance. Auparavant, il lit le fichier robots.txt ; une exclusion visant FormExposedBot ou tous les robots et couvrant la page d’accueil met fin à la vérification, de même qu’un robots.txt inaccessible ou une erreur de serveur lors de sa récupération (scanner/src/net.js). Les interdictions portant sur des sous-chemins particuliers ne sont pas respectées séparément. Le pouls du formulaire, la récupération de la preuve, l’outil d’en-têtes et la recherche de fichiers exposés ne lisent pas le robots.txt. Outre les huit pages, s’ajoutent jusqu’à trois pages avec un clic sur « Refuser » dans le bandeau cookies, jusqu’à trois pages en vue mobile, les sondes actives pour les domaines vérifiés et jusqu’à cinq pages derrière une connexion ; les pages sont chargées l’une après l’autre, et non en parallèle. Chaque requête du navigateur – y compris les redirections et les contenus intégrés – passe par un filtre qui rejette les réseaux privés et les autres ports.
Le conteneur écrit un résultat et les captures d’écran dans un répertoire temporaire. Le service de vérification transmet le résultat et les images à l’application via le réseau interne et supprime le répertoire temporaire, même en cas d’erreur (scanner/src/worker.js).
L’application traite le résultat, le compare à la vérification précédente pour les domaines des Clients et signale les modifications aux destinataires configurés par le Client.

6.2 Ce que le robot d’exploration enregistre – et ce qu’il n’enregistre pas

Élément	Ce qui est enregistré	Ce qui n’est pas enregistré	Référence source
Pages	Adresse, statut HTTP, en-têtes, Content Security Policy, hôtes tiers sollicités (au maximum 120)	Contenu de la page sous forme de texte ou de HTML	`scanner/src/crawl.js`
Champs de formulaire	Type, nom, libellé, texte indicatif, champ obligatoire, visibilité, longueur d’une valeur existante	Valeurs des champs ; pour les champs cachés, les 24 premiers caractères de la valeur sont uniquement lus pendant la vérification (pour détecter les jetons)	`scanner/src/crawl.js`
Adresses des destinataires dans le formulaire	uniquement le domaine	l’adresse	`scanner/src/crawl.js`
Scripts	Inventaire avec somme de contrôle ; adresses et texte initial sans identifiants de compte des services de publicité et d’analyse	Identifiants de compte et de pixel	`scanner/src/crawl.js`
Mouchards	quels pixels publicitaires et outils d’enregistrement se chargent avant et après le clic sur « Refuser » dans le bandeau cookies, et s’ils masquent les saisies	Identifiants des comptes auprès de ces services	`scanner/src/mitleser.js`, `scanner/src/einwilligung.js`
Texte du formulaire	jusqu’à 400 caractères sont transmis au modèle de langage local si les règles ne reconnaissent pas le type	Communication à des tiers ; enregistrement du texte	`scanner/src/classify.js`
Captures d’écran (robot d’exploration)	zone visible de la première page ; pour chaque formulaire visible, une image de l’élément de formulaire	–	`scanner/src/crawl.js`
Captures d’écran (vérification active)	Image de la page de réponse à la soumission de test ; en outre le statut, l’adresse cible, le titre et les 300 premiers caractères de son texte	–	`scanner/src/active.js`
Captures d’écran (parcours de navigateur)	Image du formulaire avec champs de saisie noircis, compressée, au maximum 32 Ko	Saisies	`scanner/src/browser.js`
Derrière la connexion	comme pour les champs de formulaire ci-dessus	Captures d’écran, cookies, liens	`scanner/src/login.js`

Ces éléments ne contiennent pas de données à caractère personnel par conception, mais ils en contiennent incidemment : le nom d’un interlocuteur à côté du formulaire, une photo d’équipe sur la page d’accueil, un numéro de téléphone dans un libellé, le domaine de messagerie d’un particulier, un nom dans un texte indicatif. Derrière la connexion s’ajoutent des informations sur le compte de test et, selon le site web, sur d’autres utilisateurs.

6.3 Qui déclenche une vérification, et ce qui s’applique alors

Déclencheur	Niveau de confiance dans la tâche	Soumissions de test	Résultat accessible via	Suppression
Quelqu’un saisit un domaine sur la page d’accueil (vérification gratuite)	anonyme	non	Rapport sous un lien aléatoire	30 jours, images comprises (`cfg/check_lib.php`)
Plugin ou extension sans compte	plugin	non	Rapport sous un lien aléatoire	30 jours
Agence pour un prospect	enregistré	non	Constat succinct et rapport sous un lien aléatoire	90 jours (`cfg/akquise_lib.php`)
Client, domaine sans preuve	enregistré	non	Compte ; rapport sous un lien aléatoire	13 mois, la dernière vérification est conservée
Client, domaine avec preuve	vérifié	oui, au maximum cinq par vérification	Compte ; rapport sous un lien aléatoire	13 mois, la dernière vérification est conservée (`cfg/fristen_lib.php`)
Étude	interne	non	uniquement des totaux après publication	à la publication ; sans publication, aucune limite de durée (R4)
Vérification interne en ligne de commande par le fournisseur	interne ; pour nos propres domaines de test et de démonstration également « vérifié »	non ; avec le niveau « vérifié », oui (uniquement nos propres domaines de test et de démonstration)	en interne uniquement	aucune limite de durée (R4)

Plusieurs couches précèdent la vérification gratuite (cfg/check_lib.php) : un arrêt d’urgence ; reCAPTCHA ; le même domaine au maximum une fois en sept jours (au-delà, le rapport existant est affiché) ; des limites par adresse IP, par session (sous forme de valeur de hachage, jamais l’identifiant de session lui-même) et pour l’ensemble du service par jour ; la liste de blocage issue de l’opt-out et du robots.txt ; la vérification que le domaine pointe vers des adresses publiques ; et un blocage des domaines très récents ou inconnus. Les anomalies – nombreux domaines différents depuis une même adresse IP, nombreuses requêtes en peu de temps – sont notées avec l’adresse IP et déclenchent un signal sans contenu (cfg/check_lib.php).

6.4 Vérification des domaines du compte Client

Le Client prouve qu’il est habilité à contrôler un domaine : par enregistrement DNS, balise meta, fichier ou via notre plugin (cfg/verify_lib.php). Ce n’est qu’alors que le domaine est considéré comme vérifié. Le planificateur de surveillance ne programme des vérifications régulières que pour les domaines actifs, surveillés et vérifiés (cfg/monitor_lib.php).

Les soumissions de test actives sont soumises à deux verrous : l’application n’active le mode actif pour les Clients que pour les domaines vérifiés (pour nos propres domaines de test et de démonstration, le fournisseur peut créer une vérification de niveau « vérifié » via un outil interne en ligne de commande), et le service de vérification contrôle à nouveau le niveau de confiance et l’arrêt d’urgence fc_active_enabled (scanner/src/worker.js). Seul peut être soumis un formulaire que les règles reconnaissent avec une grande certitude comme un formulaire de contact général, qui ne comporte pas de champs obligatoires pour de véritables données à caractère personnel et dont le domaine ne ressemble pas à celui d’une autorité publique, d’un établissement d’enseignement, d’une clinique, d’un cabinet médical, de la police ou d’un tribunal (scanner/src/classify.js). Le modèle de langage ne peut pas rendre un formulaire soumissible (scanner/src/classify.js). Au maximum cinq soumissions sont envoyées par vérification (fc_active_max_posts), clairement marquées, avec l’expéditeur dummy@formexposed.com, une adresse sous .invalid pour tester la validation des e-mails et une ligne d’en-tête supplémentaire inoffensive pour détecter l’injection d’en-têtes (scanner/src/active.js).
Les parcours de navigateur vérifient dans un navigateur des parcours de formulaire configurés jusqu’au point précédant immédiatement la soumission. Seules les requêtes GET et HEAD sont autorisées ; tout le reste est interrompu, de même que les adresses contenant des mots signifiant se déconnecter, supprimer, acheter ou payer (scanner/src/browser.js). Pour la vérification, les champs obligatoires sont remplis avec des valeurs fictives qui ne quittent jamais le navigateur.
Les fichiers exposés sont recherchés chaque semaine, uniquement pour les domaines vérifiés, avec au maximum une récupération par chemin, au maximum 8 Ko, et sans jamais enregistrer le contenu (cfg/dateien_lib.php).
Une seconde sonde indépendante a été préparée et est désactivée par défaut (browser_probe_enabled = 0). Si elle était activée, elle ne recevrait que le domaine, l’adresse, le sélecteur, les étapes et le choix du navigateur, jamais d’identifiants, de captures d’écran ni de données de visiteurs (cfg/formular_probe_lib.php).

6.5 Analyse derrière la connexion

Conditions préalables : la fonction est configurée, le domaine est vérifié, et le Client dispose d’une offre payante et est propriétaire ou administrateur de l’espace de travail (cfg/login_lib.php) ; il confirme que le compte est un compte de test disposant du moins de droits possible (cfg/login_lib.php).

Le nom d’utilisateur et le mot de passe sont immédiatement chiffrés sur le serveur web avec la clé publique du serveur d’analyse : une clé à usage unique par enregistrement (X25519), dérivation de clé (HKDF-SHA256), AES-256-GCM, liée au domaine (cfg/login_lib.php). Seul le service de vérification sur le serveur d’analyse dispose de la clé privée (scanner/src/geheim.js). Quiconque dispose du serveur web, de la base de données ou d’une sauvegarde ne possède que des données chiffrées.
L’interface n’affiche que le premier caractère et la longueur du nom d’utilisateur (cfg/login_lib.php). Les identifiants ne sont jamais affichés, jamais journalisés et jamais restitués via l’API.
Pour une vérification, l’application joint les données chiffrées à la tâche. Le service de vérification les déchiffre, efface immédiatement le champ dans la tâche et transmet les identifiants au conteneur uniquement via l’entrée standard, jamais en tant qu’arguments de ligne de commande (scanner/src/worker.js). Les restes dans les tâches interrompues sont effacés par le processus de statut au bout d’une heure (cfg/login_lib.php).
Dans le conteneur, le navigateur se connecte. Il s’interrompt si la page de connexion redirige vers un autre hôte, si le formulaire de connexion comporte un CAPTCHA (nous ne contournons pas les CAPTCHA) ou si un champ de mot de passe est encore visible après la soumission (scanner/src/login.js). Il efface ensuite le champ de mot de passe dans la mémoire de la page et oublie les identifiants (scanner/src/login.js).
Il lit au maximum cinq pages du même domaine désignées par le Client. Les adresses contenant des mots signifiant se déconnecter, supprimer, retirer ou résilier sont bloquées (scanner/src/login.js). Rien n’est soumis derrière la connexion, aucune capture d’écran n’est réalisée, et les cookies et liens ne figurent pas dans le résultat (scanner/src/login.js).
La suppression est définitive : les données chiffrées sont écrasées par des données aléatoires de même longueur, la ligne est supprimée et les tâches en attente sont vidées (cfg/login_lib.php). Lorsque le domaine est supprimé, la ligne disparaît automatiquement via une clé étrangère.

6.6 Contrôle de livraison

Le contrôle de livraison répond à la question de savoir si un e-mail issu du formulaire de contact arrive réellement, et évalue ses caractéristiques d’authenticité. Il est facultatif, désactivé par défaut et nécessite la configuration d’une boîte de contrôle (cfg/zustellung_lib.php).

Si le Client l’active, le domaine reçoit une étiquette aléatoire. Le Client saisit l’adresse de contrôle avec cette étiquette en copie cachée dans son formulaire.
Dès lors, chaque e-mail de formulaire est également envoyé à la boîte de contrôle : nos soumissions de test marquées et tous les véritables messages des visiteurs. Les e-mails sont envoyés directement à la boîte aux lettres chez Namecheap, Inc. (Private Email), Phoenix, Arizona, USA – ils n’arrivent que si les enregistrements MX de notre domaine y pointent ; via une redirection, par exemple chez le registraire de domaines Namecheap, Inc., ils n’atteignent pas la boîte aux lettres – et y restent jusqu’à leur récupération.
Le processus de statut relève la boîte aux lettres toutes les cinq minutes (srv/cron_status.php). Pour chaque e-mail, il lit les en-têtes et au maximum les 8 premiers Ko du texte, sans les marquer comme lus (cfg/zustellung_lib.php).
À partir des en-têtes, il détermine l’étiquette et donc le domaine, et à partir du texte, le cas échéant, l’identifiant de notre test (cfg/zustellung_lib.php). Sont enregistrés l’heure, le domaine et, le cas échéant, l’identifiant du test (cfg/zustellung_lib.php), pendant 180 jours (cfg/zustellung_lib.php).
À partir des en-têtes, il évalue SPF, DKIM et DMARC et enregistre le résultat avec le domaine : les résultats des contrôles, le domaine de l’adresse d’expéditeur, les domaines des signatures et l’adresse du serveur de messagerie d’envoi (cfg/zustellung_lib.php). Si le résultat se dégrade, une alerte pouvant nommer le domaine de l’expéditeur est envoyée une fois au Client (cfg/zustellung_lib.php).
Il marque ensuite chaque e-mail récupéré pour suppression, y compris celui qui n’a pu être attribué à aucun domaine, et le retire de la boîte aux lettres à la fin de la passe (cfg/zustellung_lib.php). Si la passe s’interrompt avant, les e-mails restent jusqu’à la prochaine passe réussie.
Seule la copie du test concerné vaut preuve de livraison (cfg/zustellung_lib.php). Si elle n’arrive pas dans les trois heures (delivery_wait_h), le service signale « Livraison manquante ».

Le texte des véritables messages n’est jamais écrit dans la base de données, pas plus que l’adresse du visiteur. Tous deux sont néanmoins lus : la récupération charge en mémoire les 8 premiers Ko de chaque e-mail afin d’y rechercher l’identifiant du test.

6.7 Protection en essaim

La couche de protection du plugin WordPress arrête un message comme spam et compte les domaines des liens qu’il contient. Une fois par jour, le plugin nous signale ces domaines avec leur nombre d’occurrences, au maximum 60 par jour ; ni adresses, ni texte, ni adresses IP (cfg/swarm_lib.php).
Une fois par jour, nous en établissons la liste : un domaine y est inscrit s’il a été signalé en sept jours par au moins trois sites web différents et avec au moins cinq occurrences (swarm_min_sites, swarm_window_days, cfg/swarm_lib.php). Les grands services figurant sur une liste d’exceptions fixe et les domaines de nos Clients, sous-domaines compris dans chaque cas, ne sont jamais inscrits (cfg/swarm_lib.php).
La liste est transmise à tous les sites web connectés avec la réponse au signalement quotidien. Leur couche de protection place les messages contenant des liens vers des domaines inscrits en quarantaine, et non à la corbeille.
Ce qui ne figure plus dans la nouvelle liste en sort ; les signalements sont supprimés après 30 jours (cfg/swarm_lib.php).
Les réseaux IP (/24 ou /48) ont été préparés mais sont désactivés jusqu’à l’achèvement de l’examen juridique (cfg/swarm_lib.php).

6.8 Utilisation de l’intelligence artificielle

Un modèle de langage fonctionne sur notre propre serveur d’analyse, et non chez un fournisseur d’IA. Il est utilisé à deux endroits : dans le service de vérification, il classe les formulaires dont les règles ne reconnaissent pas le type ; il voit pour cela le titre de la page, l’adresse de la page, les libellés des boutons d’envoi, les types de champs, les noms, les libellés et les textes indicatifs, ainsi que jusqu’à 400 caractères de texte du formulaire (scanner/src/classify.js). Il n’est sollicité que si les règles renvoient « inconnu » ; les formulaires ainsi classés ne sont jamais soumis et ne comptent pas dans le score et le verdict. Le score, le verdict, la prévention des abus, la protection en essaim et les règles anti-spam sont des règles fixes, et non de l’IA. Dans « Fix it for me », il réécrit le code de formulaire collé ; le code n’est pas enregistré. Le modèle ne prend aucune décision concernant des personnes. Pour en savoir plus, consultez la page Règlement européen sur l’IA : comment formexposed utilise l’IA.

6.9 Bases juridiques

Opération de traitement	Base juridique
P1 Vérification gratuite : vérification du domaine demandé ; limites et prévention des abus	à l’égard de la personne qui fait la demande, Art. 6(1)(b) ; à l’égard de l’exploitant et des personnes représentées, Art. 6(1)(f) ; prévention des abus, Art. 6(1)(f)
P2 Vérification de prospects	Art. 6(1)(f) (intérêt légitime de l’agence et de formexposed)
P3 Étude	Art. 6(1)(f)
P4 Vérification des domaines des Clients	Art. 6(1)(b) à l’égard du Client ; pour les données de tiers sur son site web, les instructions du Client au titre de l’Art. 28
P5 Analyse derrière la connexion	Instructions du Client au titre de l’Art. 28 ; base juridique du Client
P6 Contrôle de livraison	Instructions du Client au titre de l’Art. 28 ; base juridique du Client (dans notre proposition de texte pour les Clients, Art. 6(1)(f))
P7 Protection en essaim	Art. 6(1)(f) (défense commune contre le spam sur de nombreux sites web)

Notre intérêt légitime pour P1 à P3 consiste à montrer aux exploitants et à leurs prestataires les faiblesses de leurs formulaires avant qu’elles ne soient exploitées à des fins de spam ou d’abus, et à fournir le service. Les données proviennent de sources accessibles au public. La mise en balance des intérêts est exposée à la section 7 ; la question de savoir si l’Art. 6(1)(f) justifie la vérification de sites web de tiers sur demande reste ouverte pour l’examen juridique.

6.10 Destinataires et transferts vers des pays tiers

Destinataire	Quoi	Opération de traitement	Statut
Personne en dehors de formexposed	Résultats de vérification, captures d’écran, classification par le modèle de langage	P1–P5	Le service de vérification et le modèle de langage fonctionnent sur nos propres serveurs ; dans le chemin de vérification du robot d’exploration, aucun appel à un tiers n’a été constaté, hormis vers le site web vérifié lui-même, vers les services dont il intègre les contenus (comme pour tout visiteur) et vers le service RDAP rdap.org pour l’âge du domaine (uniquement le nom de domaine) ; les surveillances sont énumérées à la ligne suivante
Toute personne connaissant le lien	Rapport avec constats et captures d’écran	P1, P2, P4	lien aléatoire de 128 bits (`cfg/check_lib.php`), pages avec `noindex` (`www/report.php`)
Services interrogés par la surveillance d’un domaine Client	Listes de blocage DNS (SpamCop, PSBL, Mailspike, SURBL) : domaines et adresses IP de serveurs, aucune donnée de visiteurs ; Google Web Risk uniquement s’il est configuré : l’adresse de la page d’accueil ; autorités d’horodatage Certum et DigiCert : uniquement une valeur de hachage du journal de preuve ; RDAP via le registre de l’IANA : uniquement le nom de domaine ; pages de statut des fournisseurs : rien n’est transmis ; wpvulnerability.net : identifiant d’un plugin (sans version) ou d’un thème et version de WordPress	P4	en service ; détails dans le Registre des activités de traitement et sur la page Sous-traitants ultérieurs
Namecheap, Inc. (Private Email), Phoenix, Arizona, USA	Copies de contrôle, y compris les véritables messages de visiteurs	P6	Contrat pas encore conclu ; lieu de traitement et mécanisme de transfert encore à examiner
Namecheap, Inc. (États-Unis)	Registraire et DNS ; jusqu’à la mise en place de la boîte aux lettres, redirection des e-mails généraux vers des adresses de notre domaine, mais pas des copies de contrôle (celles-ci n’atteignent la boîte aux lettres que via des enregistrements MX pointant directement vers elle)	– (pas de copies de contrôle)	Mécanisme de transfert à examiner
Canaux d’alerte choisis par le Client (e-mail, webhook, Slack, Discord, Microsoft Teams, Google Chat, Telegram)	Événement, domaine, lien ; pour le contrôle d’authenticité, le domaine de l’expéditeur s’il n’appartient pas au site web	P4, P6	destination choisie par le Client ; en partie hors de l’UE. Nous envoyons les messages Telegram via notre bot ; le mécanisme de transfert correspondant est une question ouverte pour l’examen juridique
Tous les sites web connectés	Liste des domaines de liens	P7	via la réponse au plugin
Seconde sonde	Domaine, adresse du formulaire, sélecteur, étapes	P4	désactivée

6.11 Conservation, mesurée et non souhaitée

La suppression a lieu pour l’essentiel la nuit à 03:00 dans le processus de statut (srv/cron_status.php, cfg/fristen_lib.php) ; les signalements de la protection en essaim et les lignes de prospects sont supprimés chaque jour à partir de 04:00, les correspondances du contrôle de livraison à chaque récupération ; les rapports anonymes et de prospects sont supprimés via leur date d’expiration (cfg/check_lib.php). Les captures d’écran sont supprimées du disque avec leur analyse (cfg/fristen_lib.php).

Données	Durée selon le code	Référence source	Constat
Vérification gratuite, images comprises	30 jours	`cfg/check_lib.php`	effective
Vérification de prospects, images comprises	90 jours	`cfg/akquise_lib.php` ; `srv/cron_status.php` (lignes de prospects)	effective
Vérifications d’un domaine Client	13 mois ; la dernière est conservée tant que le domaine existe	`cfg/fristen_lib.php`	effective
Résultats des parcours de navigateur, images noircies comprises	13 mois	`cfg/fristen_lib.php`	effective
Données d’un domaine supprimé	immédiatement ; orphelins la nuit	`cfg/fristen_lib.php` (`fe_domain_loeschen()`, `fe_fristen_lauf()`)	effective, y compris l’inventaire des scripts et les modifications de scripts, qui n’ont pas de durée de conservation propre au-delà (voir le Registre des activités de traitement)
Étude : données brutes, images comprises	à la publication	`cfg/studie_lib.php`	sans publication, aucune limite de durée ; la liste des hôtes vérifiés est conservée sans limite de durée même après publication
Vérifications internes sans domaine ni rapport	aucune	–	aucune suppression ; mesuré : 85 vérifications avec 369 images depuis le 22 septembre 2026 (R4)
Correspondances du contrôle de livraison	180 jours	`cfg/zustellung_lib.php`	effective
Résultat du contrôle d’authenticité lié au domaine	jusqu’au résultat suivant ou à la suppression du domaine	`cfg/zustellung_lib.php`	écrasé, sans limite de durée
Copies de contrôle dans la boîte aux lettres	jusqu’à la prochaine récupération réussie (intervalle de cinq minutes)	`cfg/zustellung_lib.php`	copies et sauvegardes chez le fournisseur de la boîte aux lettres non vérifiées
Identifiants pour l’analyse derrière la connexion	jusqu’à la suppression par le Client ou celle du domaine ; dans la tâche au plus jusqu’à la fin de l’exécution, restes après une heure	`cfg/login_lib.php`	effective ; dans les sauvegardes uniquement sous forme chiffrée pendant jusqu’à 14 jours
Signalements de la protection en essaim	30 jours	`cfg/swarm_lib.php`	effective
Limites de la vérification gratuite (IP, pays, hachage de session)	7 jours	`srv/cron_status.php`	effective
Notes sur un comportement suspect avec adresse IP	90 jours après résolution	`srv/cron_status.php`	notes non résolues sans limite de durée ; mesuré : 3 notes, toutes résolues
Adresse IP, pays, navigateur liés à un opt-out	12 mois ; l’exclusion est conservée	`cfg/fristen_lib.php`	effective
Sauvegardes de la base de données	14 jours	`cfg/backup_lib.php`	effective ; les sauvegardes sont actuellement stocké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 (R13)

7. (b) Évaluation de la nécessité et de la proportionnalité

L’étalon de mesure est constitué par les finalités déclarées : montrer aux exploitants si leurs formulaires sont protégés contre le spam et les abus (P1 à P5), vérifier si les e-mails de formulaire arrivent et paraissent authentiques (P6), et se défendre en commun contre le spam sur de nombreux sites web (P7). Ces finalités sont légitimes. La question posée par l’Art. 35(7)(b) est plus étroite : ce traitement est-il nécessaire à cette profondeur pour la finalité, et l’ingérence est-elle proportionnée au bénéfice ?

Composant	Nécessaire à la finalité ?	Proportionné sous la forme développée ?
Récupération de quelques pages publiques, structure des formulaires, mesures de protection détectées	Oui. Sans cela, pas de constat.	Oui. Au maximum huit pages (plus les vues de la section 6.1), une interdiction de la page d’accueil dans le robots.txt est respectée, aucune valeur de champs visibles, adresses des destinataires uniquement sous forme de domaine.
Capture d’écran par formulaire	Oui, à titre de preuve dans le rapport : l’exploitant voit de quel formulaire il s’agit.	En grande partie. Les champs sont vides, car le robot d’exploration n’y saisit rien. L’image montre toutefois l’environnement de l’élément de formulaire sans rien noircir (R3).
Capture d’écran de la page d’accueil	Non requise pour le constat lui-même. Elle sert à reconnaître le site web vérifié dans le rapport.	Seulement dans une mesure limitée ; minimisation supplémentaire prévue. Les pages d’accueil montrent souvent des personnes : photos d’équipe, interlocuteurs, témoignages de clients avec leur nom. Voir R3 et la section 9.3.
Lecture des valeurs des champs cachés (24 premiers caractères, uniquement pendant la vérification)	Oui : les jetons et horodatages sont détectés à partir de celles-ci.	Oui. Seul le résultat de la détection est enregistré, pas la valeur, y compris derrière la connexion (R8).
Page de réponse à la soumission de test (image et 300 caractères de texte)	Oui, à titre de preuve de la réaction du formulaire.	Oui. La réponse porte sur notre message de test marqué, sans données à caractère personnel.
Classification par le modèle de langage	Utile, pas nécessaire : sans elle, davantage de formulaires restent « inconnus ».	Oui. Locale, sans communication, sans droit de soumission.
Soumissions de test actives	Oui. L’efficacité d’une protection n’apparaît que lorsqu’elle est testée.	Oui, avec plafond et marquage. La condition préalable – la preuve de contrôle – n’est toutefois jamais renouvelée (R7).
Recherche de fichiers exposés	Oui pour le Client, dont les données de formulaire peuvent y être exposées.	Oui. Uniquement les domaines vérifiés, au maximum 8 Ko, contenu jamais enregistré.
Analyse derrière la connexion	Oui pour les formulaires de l’espace membres qui resteraient sinon non vérifiés.	En grande partie. Le chiffrement et la suppression sont soigneusement conçus ; la connexion accepte toutefois des connexions non chiffrées et des certificats défectueux (R8).
Copie de contrôle des véritables messages de visiteurs	Pas pour la preuve de livraison. Celle-ci repose uniquement sur la copie de notre test (`cfg/zustellung_lib.php`). Les véritables messages suivent parce qu’une copie cachée dans le formulaire ne distingue pas un test d’un véritable message. Ils sont utiles pour le contrôle d’authenticité (SPF, DKIM, DMARC), car ils montrent le chemin d’envoi réel.	En partie. Le contenu n’est pas enregistré, mais il est lu, et il reste chez le fournisseur de la boîte aux lettres, dont le contrat est encore en suspens, jusqu’à la récupération (R1, R2). Une conception moins intrusive est techniquement possible : avec notre plugin, la copie cachée pourrait être limitée aux messages de test marqués (section 9.3).
Enregistrement du domaine de l’expéditeur des véritables messages	En partie : il indique si le formulaire envoie avec l’adresse du visiteur comme expéditeur (cause fréquente de classement en spam).	Sous conditions. Pour un particulier disposant de son propre domaine, le domaine est une donnée à caractère personnel, et il figure dans l’alerte envoyée au Client et à ses canaux (R1).
Liste commune de domaines de liens	Oui. Un lien de spam qui apparaît simultanément sur de nombreux sites web est un signal fort dont un site web isolé ne dispose pas.	Oui, avec des seuils minimaux, des exceptions et la quarantaine au lieu de la suppression. Les réseaux IP ne seraient pas proportionnés sans une nouvelle analyse.
Données brutes de l’étude	Jusqu’à l’évaluation, oui.	Sans durée maximale, non (R4).
Rapport sous un lien aléatoire	Oui. Transmettre le rapport – par exemple au prestataire qui s’occupe du site web – est la finalité de la vérification gratuite.	Oui. Lien aléatoire de 128 bits, `noindex`, rapport gratuit uniquement sous forme d’extrait (`cfg/check_lib.php`, `FE_FREE_DETEKTOREN`), suppression après 30 jours.

Licéité. Pour P1 à P3 et P7, nous nous fondons sur l’Art. 6(1)(f). En faveur de la mise en balance : les données sont publiques et sont consultées de la même manière que par n’importe quel visiteur ; rien n’est soumis ; les données à caractère personnel sont incidentes et mineures ; les durées sont courtes ; l’exploitant peut exclure d’autres vérifications par le robot d’exploration au moyen d’une interdiction de la page d’accueil dans le robots.txt, et toute autre vérification via notre page d’opt-out, immédiatement et sans preuve ; le bénéfice – un formulaire protégé – profite aussi à l’exploitant et à ses visiteurs. En sa défaveur : l’exploitant n’apprend rien de la vérification, le rapport est destiné à des tiers et, dans le cas des entrepreneurs individuels, il évalue une personne. Nous estimons la mise en balance défendable tant que les mesures de la section 9.1 restent en place ; une confirmation juridique est en attente.

Information des personnes concernées (Art. 13 et 14). Nous informons les exploitants et les personnes présentes sur les pages vérifiées par la page du robot d’exploration, mentionnée dans l’identifiant de chaque consultation, par la Politique de confidentialité et par la page d’opt-out. Informer individuellement les personnes apparaissant incidemment sur une capture d’écran ne serait possible qu’en les identifiant – ce qui constituerait une ingérence supplémentaire et plus grave. Dans cette mesure, nous nous fondons sur l’Art. 14(5)(b). Les visiteurs dont les messages transitent par la copie de contrôle sont informés par le Client ; le Contrat de sous-traitance l’exige, et nous fournissons à cet effet un bloc de texte.

Minimisation des données (Art. 5(1)(c)). Elle est visible à de nombreux endroits et ancrée dans le code : aucune valeur de champ, adresses des destinataires uniquement sous forme de domaine, identifiants de compte masqués dans les adresses de scripts, aucun contenu de la copie de contrôle dans la base de données, aucune capture d’écran derrière la connexion, uniquement des domaines dans la protection en essaim. À deux endroits, une minimisation supplémentaire est possible et prévue (section 9.3) : pour la capture d’écran de la page d’accueil sans noircissement et pour le domaine de l’expéditeur des véritables messages.

Limitation de la conservation (Art. 5(1)(e)). Depuis le 27 septembre 2026, la passe nocturne respecte les durées indiquées dans la Politique de confidentialité pour les données des Clients et efface les données restées sans domaine associé de la période antérieure (cfg/fristen_lib.php). Deux voies sans limite de durée restent ouvertes : les vérifications internes et les études non publiées (R4).

Exactitude (Art. 5(1)(d)). Un constat peut être erroné : un formulaire paraît non protégé parce que la protection ne se charge qu’après une interaction, ou le robot d’exploration a été traité différemment d’un visiteur par un pare-feu. Pour un exploitant dont le site web circule publiquement avec la mention « Exposé », c’est une question de réputation. Le rapport nomme donc la méthode, présente des preuves et signale les limites d’une vérification depuis l’extérieur.

Résultat sur la proportionnalité : la vérification de sites web de tiers et de sites propres est, sous la forme développée, pour l’essentiel proportionnée. À trois endroits, il existe un besoin d’amélioration auquel il peut être remédié par des moyens ordinaires et pour lequel des mesures sont prévues (section 9.3) : les captures d’écran de la page d’accueil, les vérifications internes sans limite de durée et la connexion non chiffrée pour l’analyse derrière la connexion. Le contrôle de livraison est proportionné pour la copie de test et pour le contrôle d’authenticité ; pour les véritables messages de visiteurs, il ne l’est que tant que leur contenu n’est pas enregistré, que le passage par le fournisseur de la boîte aux lettres est contractuellement sécurisé et que le Client informe ses visiteurs. Aujourd’hui, le deuxième de ces trois points fait défaut.

8. (c) Évaluation des risques pour les droits et libertés des personnes concernées

Ce qui est évalué, c’est le risque pour les personnes concernées, et non pour formexposed. La vraisemblance est cotée comme faible, possible, probable ou réalisée ; « réalisée » signifie que l’événement n’est pas une prévision mais un état mesuré. La gravité est cotée comme limitée, importante, grave ou très grave, selon ce que la personne risque de perdre : la confidentialité de son message, le contrôle d’un compte, sa réputation professionnelle, la possibilité d’exercer un droit. Le niveau résulte des deux et décrit l’état actuel avec les mesures de la section 9.1.

N°	Risque	Opération de traitement	Vraisemblance	Gravité	Niveau
R1	Véritables messages de visiteurs dans la copie de contrôle, y compris d’éventuelles catégories particulières	P6	Réalisée dès l’activation	Grave	Élevé
R2	Passage de la copie de contrôle par le fournisseur de la boîte aux lettres sans contrat conclu et avec un éventuel lien avec un pays tiers	P6	Probable tant que le contrat fait défaut	Grave	Élevé
R3	Captures d’écran de sites web de tiers sans noircissement	P1–P4	Probable	Limitée	Moyen
R4	Données de vérification et captures d’écran sans voie de suppression	P3, vérifications internes	Réalisée	Importante	Élevé
R5	Vérification et évaluation publique de sites web de tiers à l’insu de l’exploitant ; détournement en outil de reconnaissance	P1	Possible	Importante	Moyen
R6	Vérification de prospects comme base de démarchage non sollicité	P2	Probable	Limitée	Moyen
R7	La preuve de contrôle n’est jamais renouvelée	P4, P5	Possible	Importante	Moyen
R8	Identifiants et contenus dans l’analyse derrière la connexion	P5	Possible	Grave	Moyen ; élevé pour de vrais comptes
R9	Soumissions de test actives et vérification des fichiers sur le site web du Client	P4	Faible	Importante	Faible
R10	Classification par un modèle de langage	P1–P4	Faible	Limitée	Faible
R11	Liste de blocage commune issue des signalements de nombreux sites web	P7	Possible	Limitée	Faible à moyen ; élevé avec les réseaux IP
R12	Rapports et captures d’écran sous un lien public	P1, P2, P4	Possible	Limitée	Faible
R13	Faiblesses de l’infrastructure : sauvegardes, accès aux serveurs, serveur d’analyse	toutes	Possible	Grave	Élevé
R14	Droits des personnes concernées pour des personnes qui ne nous connaissent pas	P1–P6	Probable	Limitée	Faible

R1 – Véritables messages de visiteurs dans la copie de contrôle

C’est le risque le plus grave du service, et il ne résulte pas d’une erreur mais de la conception. Une copie cachée dans le formulaire ne distingue pas notre message de test du message d’un visiteur. Si un Client active le contrôle de livraison, chaque message envoyé via ce formulaire parvient à notre boîte de contrôle (cfg/zustellung_lib.php). La récupération charge en mémoire les en-têtes et les 8 premiers Ko du texte afin d’y rechercher notre identifiant de test (cfg/zustellung_lib.php). Pour un formulaire de contact ordinaire, cela signifie le nom, l’adresse e-mail, le numéro de téléphone et le message complet.

Ce que le visiteur écrit lui appartient, et le champ invite à un contenu personnel : une demande de rendez-vous décrivant des symptômes à un cabinet médical, l’exposé d’un litige à un cabinet d’avocats, une candidature, une demande concernant un enfant à une école. Nos documents juridiques indiquent que les copies « ne devraient contenir aucune catégorie particulière de données à caractère personnel ». C’est une demande adressée au Client, et non une mesure de protection : ni lui ni nous ne savons à l’avance ce qu’un visiteur écrira.

Deux voies accessoires s’y rattachent. Premièrement, le contrôle d’authenticité enregistre le domaine de l’adresse d’expéditeur avec le domaine (cfg/zustellung_lib.php). Si le formulaire envoie avec l’adresse du visiteur comme expéditeur, il s’agit du domaine du visiteur – sans signification pour un grand fournisseur de messagerie, mais une donnée à caractère personnel pour un particulier disposant de son propre domaine. Ce domaine apparaît également dans l’alerte envoyée au Client et aux canaux qu’il a choisis (cfg/zustellung_lib.php). Deuxièmement, il enregistre l’adresse du serveur de messagerie d’envoi (cfg/zustellung_lib.php) ; en règle générale, il s’agit du serveur du site web, et non de celui du visiteur.

Vraisemblance – réalisée dès l’activation. La question n’est pas de savoir si de véritables messages arrivent, mais combien. Mesuré sur le système de développement, la fonction n’est activée pour aucun domaine. Gravité – grave. La confidentialité d’un message adressé à une entreprise importe à de nombreuses personnes, et des données au sens de l’Art. 9 sont à prévoir chez une partie des Clients types. La gravité est atténuée par le fait que le contenu n’aboutit pas dans la base de données, ne reste que brièvement dans la boîte aux lettres et n’est lu par aucune personne chez formexposed. Niveau – élevé.

R2 – Passage de la copie de contrôle par le fournisseur de la boîte aux lettres sans contrat conclu

Avant que notre récupération ne voie une copie de contrôle, celle-ci est conservée dans la boîte aux lettres chez Namecheap, Inc. (Private Email), Phoenix, Arizona, USA. Elle n’y arrive que si les enregistrements MX de notre domaine pointent directement vers cette boîte aux lettres ; la redirection chez le registraire de domaines Namecheap, Inc. n’est pas une étape des copies de contrôle (via une redirection, elles n’atteignent pas la boîte aux lettres). Pour l’étape qui subsiste, les dispositions contractuelles sont encore en suspens : le contrat avec le fournisseur de la boîte aux lettres n’a pas été conclu, ses lieux de stockage, sous-traitants ultérieurs et durées de sauvegarde n’ont pas été établis, et la question de savoir si une décision d’adéquation ou des clauses contractuelles types sont nécessaires pour son lieu de traitement et s’appliquent reste ouverte. Pour nos propres e-mails transactionnels, il s’agit d’une question de rédaction contractuelle. Pour les copies de contrôle, c’est plus grave : il s’agit là de données que nous recevons en tant que sous-traitant, et chaque prestataire sur le chemin est un sous-traitant ultérieur dont nous répondons au titre de l’Art. 28(4).

En outre, « supprimé après récupération » ne vaut que pour notre vue de la boîte aux lettres. Si le fournisseur conserve les e-mails supprimés dans ses propres sauvegardes ou dans une corbeille, et pendant combien de temps, n’a pas été vérifié. Si une récupération s’interrompt, les e-mails restent jusqu’à la prochaine passe réussie (cfg/zustellung_lib.php) ; si le processus de statut tombe en panne, ils restent indéfiniment. Enfin, la sécurisation de la récupération elle-même fait partie des points à vérifier sur le système de production avant le lancement (section 9.3).

Vraisemblance – probable tant que le contrat fait défaut : chaque copie de contrôle emprunte ce chemin. Gravité – grave, pour les mêmes raisons que R1. Niveau – élevé. La liste de configuration de l’application signale l’absence de boîte aux lettres par un avertissement ; il n’existe aucun verrou bloquant le contrôle de livraison en l’absence de contrat documenté.

R3 – Captures d’écran de sites web de tiers sans noircissement

Le robot d’exploration réalise une capture d’écran de la zone visible de la première page et une image de l’élément de formulaire de chaque formulaire visible (scanner/src/crawl.js). Rien n’est noirci à cette occasion. Il en va autrement pour les parcours de navigateur : les champs de saisie y sont masqués avant la capture d’écran (scanner/src/browser.js). Seules les images des parcours de navigateur sont donc « nettoyées », et non celles du robot d’exploration ni l’image de la page de réponse d’une vérification active.

Comme le robot d’exploration ne saisit rien, les champs de formulaire sont vides. Toutefois, la page d’accueil d’une petite entreprise montre souvent le propriétaire, l’équipe, des témoignages de clients avec noms et photos, ou une fenêtre de chat avec la photo d’un salarié. Tout cela est public ; la capture d’écran en fait une copie conservée chez nous, qui figure dans le rapport et peut être transmise avec le lien.

Vraisemblance – probable. 432 captures d’écran ont été mesurées dans le jeu de données du système de développement. Gravité – limitée : le contenu est déjà public, et les durées pour les vérifications sans compte sont courtes. Niveau – moyen, parce que les personnes représentées n’en ont pas connaissance et que l’image de la page d’accueil n’est pas nécessaire au constat.

R4 – Données de vérification et captures d’écran sans voie de suppression

La passe nocturne supprime les vérifications par deux voies : via la date d’expiration d’un rapport (cfg/check_lib.php) et via la durée applicable aux vérifications d’un domaine Client (cfg/fristen_lib.php, uniquement pour les vérifications avec domaine). Une vérification qui n’a ni rapport ni domaine passe entre les deux filets. Il s’agit des vérifications de niveau de confiance « interne » : les études et les vérifications que le fournisseur crée en ligne de commande.

Les études suppriment leurs données brutes lors de la publication (cfg/studie_lib.php). Si une étude n’est jamais publiée – parce qu’elle compte trop peu de sites web disposant d’un formulaire (cfg/studie_lib.php refuse alors la publication) ou parce qu’elle est laissée de côté – les vérifications, formulaires, constats et captures d’écran sont conservés sans limite de durée.
Les vérifications internes en ligne de commande n’ont aucune voie de suppression. Mesuré le 11 octobre 2026 : 85 vérifications de ce type portant sur des sites web de tiers, avec 978 formulaires et 369 captures d’écran, la plus ancienne du 22 septembre 2026, aucune avec un rapport ou un domaine.
Les notes sur un comportement suspect lors de la vérification gratuite contiennent l’adresse IP et sont supprimées 90 jours après leur résolution (srv/cron_status.php). Une note qui n’est jamais résolue est conservée. Mesuré : trois notes, toutes résolues.

Vraisemblance – réalisée. Les 85 vérifications ne sont pas un scénario mais des données existantes. Sur le système de développement, il s’agit de vérifications issues d’un essai en conditions réelles ; le même code s’applique sur le système de production. Gravité – importante : il n’existe aucune durée de conservation pour ces données. Au regard du principe de limitation de la conservation (Art. 5(1)(e)), il s’agit d’un point ouvert assorti d’une mesure prévue (section 9.3, priorité « en premier »), et il touche précisément des personnes qui ignorent tout de la vérification. Les vérifications internes sont décrites dans le Registre des activités de traitement ; la Politique de confidentialité ne les mentionne pas encore séparément (section 9.4). Niveau – élevé.

R5 – Vérification et évaluation publique de sites web de tiers à l’insu de l’exploitant

Toute personne peut faire vérifier n’importe quel site web accessible au public, sans compte et sans aucun lien avec celui-ci. L’exploitant n’en est pas informé. Le résultat est un rapport qui qualifie le site web d’« Exposé », de « Partiellement protégé » ou de « Protégé » et que toute personne disposant du lien peut consulter. Deux conséquences sont envisageables pour les personnes concernées. Un entrepreneur individuel se voit attribuer publiquement – ne serait-ce que pour les destinataires du lien – une évaluation qui peut constituer un faux constat. Et le rapport montre à un spammeur quel formulaire peut être rempli sans obstacle.

Une série de blocages s’y oppose (cfg/check_lib.php) : au maximum une vérification par domaine en sept jours, au-delà le même rapport ; des limites par adresse IP et par session ; un plafond quotidien pour l’ensemble du service ; aucune vérification de domaines très récents, typiques des abus ; une note et un signal en cas de comportement suspect ; robots.txt et opt-out, vérifiés deux fois (cfg/check_lib.php et dans le service de vérification). Le rapport gratuit est un extrait : il ne montre que les constats de base, pas les preuves de tous les détecteurs. Et il ne dit rien qu’un bot ne pourrait découvrir lui-même en quelques secondes – un formulaire non protégé est visible de l’extérieur.

Vraisemblance – possible. Gravité – importante pour un entrepreneur individuel dont le formulaire est pris pour cible après un rapport ou dont l’évaluation est erronée. Niveau – moyen.

R6 – Vérification de prospects comme base de démarchage non sollicité

Dans l’interface, la vérification de prospects est présentée comme une « porte d’entrée pour le premier entretien ». L’usage que l’agence fait du constat succinct relève de sa décision ; techniquement, elle peut aussi l’envoyer à un exploitant qui ne l’a pas demandé. Nous ne contactons personne (cfg/akquise_lib.php), et les Conditions d’utilisation obligent l’agence à respecter les règles relatives à la publicité et à la prospection. Un e-mail non sollicité contenant le constat constitue toutefois de la prospection directe, même entre entreprises, ce qui exige un consentement préalable en Pologne (Art. 398 de la Prawo komunikacji elektronicznej (loi sur les communications électroniques), PKE) et en Allemagne (§ 7(2) de la Gesetz gegen den unlauteren Wettbewerb (loi allemande contre la concurrence déloyale), UWG). L’interface ne le signale pas ; les textes de la vérification de prospects ne parlent que de « passif » et de « liste d’opposition ».

Vraisemblance – probable, car la fonction sert à l’acquisition de clients et nous ne pouvons pas vérifier si le destinataire a consenti. Gravité – limitée : pour l’exploitant, il s’agit d’un e-mail publicitaire importun contenant une évaluation de son site web. Niveau – moyen. Le risque réside dans le comportement de l’agence ; comme la fonction provient de nous, un avertissement dans l’interface est prévu (section 9.3).

R7 – La preuve de contrôle n’est jamais renouvelée

Les soumissions de test actives, la recherche de fichiers exposés et l’analyse derrière la connexion exigent que le Client ait prouvé qu’il est habilité à contrôler le domaine. Cette preuve est vérifiée une seule fois (cfg/verify_lib.php) et plus jamais ensuite. Il n’existe dans le code aucune voie par laquelle un domaine perdrait sa preuve. Si le domaine change de propriétaire, si une agence met fin à son mandat ou si l’exploitant supprime l’enregistrement DNS, les vérifications se poursuivent – jusqu’à une fois par jour, avec jusqu’à cinq soumissions de test et, le cas échéant, avec la connexion d’un compte de test dont le nouvel exploitant n’a peut-être pas connaissance. Il n’est en revanche pas possible de transférer la preuve à un autre hôte par renommage : le nom d’hôte d’un domaine disposant d’une preuve de contrôle ne peut pas être modifié.

Vraisemblance – possible : les changements de domaine et de mandat sont monnaie courante pour les agences. Gravité – importante pour le nouvel exploitant et ses salariés, qui reçoivent des messages de test marqués et dont le site web fait l’objet d’une recherche de fichiers exposés sans leur consentement. Niveau – moyen. Les messages de test s’expliquent d’eux-mêmes et renvoient à la page du robot d’exploration et à l’opt-out ; l’opt-out fonctionne également contre les vérifications des Clients.

R8 – Identifiants et contenus dans l’analyse derrière la connexion

Le chiffrement des identifiants est soigneusement conçu : le serveur web ne peut plus les lire après leur enregistrement, la base de données et la sauvegarde ne contiennent que des données chiffrées, l’enregistrement est lié à son domaine, les identifiants n’entrent dans le conteneur que via l’entrée standard et sont ensuite effacés de la mémoire (section 6.5). Deux lacunes subsistent ; un troisième point ne concerne que la lecture, pas l’enregistrement.

La connexion non chiffrée est autorisée. La vérification de l’adresse admet http en plus de https (cfg/login_lib.php, scanner/src/login.js). Si le Client saisit une page de connexion en http, le nom d’utilisateur et le mot de passe transitent en clair sur Internet à chaque vérification.
Les erreurs de certificat n’interrompent pas la connexion. La connexion ne s’interrompt pas actuellement lorsque le certificat du site du Client est invalide (scanner/src/login.js). Le certificat ne protège donc pas pleinement les identifiants sur leur chemin vers le site du Client. L’interruption en cas d’erreur de certificat est prévue (section 9.3, priorité « en premier »).
Les valeurs des champs cachés derrière la connexion sont lues, pas enregistrées. Le robot d’exploration lit les 24 premiers caractères de la valeur des champs cachés (scanner/src/crawl.js), et la même fonction d’extraction s’exécute derrière la connexion (scanner/src/login.js). Là, les champs cachés contiennent fréquemment un numéro de compte, un identifiant d’utilisateur ou l’adresse e-mail du compte connecté ; toutefois, seuls le nom du champ, le type, le libellé et le résultat de la détection figurent dans la cartographie des champs et les constats.

À cela s’ajoute ce que le code ne peut pas empêcher : le Client confirme qu’il utilise un compte de test disposant du moins de droits possible (cfg/login_lib.php), mais il peut saisir un véritable compte administrateur. Les pages que le scanner lit alors sont déterminées par le Client ; les adresses contenant des mots signifiant se déconnecter et supprimer sont bloquées, mais pas les autres actions qu’un site web déclenche par une simple requête.

Vraisemblance – possible. Gravité – grave si un compte disposant de droits étendus est concerné ; l’espace membres contenant les données de tous les utilisateurs est alors ouvert. Niveau – moyen pour un compte de test disposant de peu de droits, élevé pour un véritable compte. Mesuré sur le système de développement, aucun compte de test n’est enregistré.

R9 – Soumissions de test actives et vérification des fichiers sur le site web du Client

Une soumission de test parvient aux personnes qui lisent les e-mails de formulaire du Client – ses salariés ou un prestataire. Elle ne contient aucune donnée à caractère personnel : l’expéditeur est dummy@formexposed.com, le texte et l’objet sont marqués et indiquent l’identifiant de la vérification (scanner/src/active.js). Le risque réside dans une erreur de classification : si le scanner prenait un formulaire de candidature, de réservation ou de conseil pour un formulaire de contact, le message de test aboutirait dans un processus qui a des conséquences. S’y opposent les règles strictes pour « soumissible » (scanner/src/classify.js), le blocage des domaines d’autorités publiques, d’établissements d’enseignement, de cliniques, de cabinets médicaux, de la police et des tribunaux (scanner/src/classify.js) et l’exclusion du modèle de langage de cette décision (scanner/src/classify.js). De la réponse sont enregistrés le statut, l’adresse cible, le titre, 300 caractères de texte et une image ; ils portent sur notre message de test.

La vérification des fichiers lit au maximum 8 Ko à partir de chemins typiques. Si un dump de base de données y est réellement exposé, ces 8 Ko peuvent contenir des saisies de formulaire effectuées par des visiteurs. Ils ne sont examinés qu’à la recherche d’une signature puis écartés (cfg/dateien_lib.php) ; sont enregistrés le chemin, le type et la gravité.

Vraisemblance – faible. Gravité – importante. Niveau – faible. Mesuré sur le système de développement, le jeu de données contient une vérification active, sans soumission acceptée.

R10 – Classification par un modèle de langage

Pour les formulaires que les règles ne reconnaissent pas, le modèle de langage reçoit le titre de la page, l’adresse, les textes des boutons, les descriptions des champs et jusqu’à 400 caractères de texte du formulaire (scanner/src/classify.js). Cela peut inclure un nom, par exemple « Votre interlocuteur : … ». Il fonctionne sur notre propre serveur ; dans le code, rien n’est transmis à un tiers. Si le logiciel du modèle journalise les requêtes n’a pas été vérifié. Son résultat ne détermine que le type de formulaire affiché et ne peut pas rendre un formulaire soumissible ; une classification erronée conduit à un constat moins bon, et non à une action.

Vraisemblance – faible. Gravité – limitée. Niveau – faible.

R11 – Liste de blocage commune issue des signalements de nombreux sites web

Un domaine inscrit sur la liste a pour effet que les messages contenant des liens vers lui sont placés en quarantaine sur tous les sites web connectés. Si le domaine appartient à un particulier – un artisan, un photographe, un blog – ses messages contenant un lien vers son propre site web parviennent en retard aux destinataires. Un tel domaine peut se retrouver sur la liste parce que des spammeurs en abusent, ou parce que quelqu’un envoie délibérément à plusieurs sites web des messages bloqués le contenant.

S’y opposent (cfg/swarm_lib.php) : un minimum de trois sites web différents et de cinq occurrences en sept jours ; des exceptions fixes pour les grands services ; jamais les domaines de nos Clients ; un retrait manuel via un outil sur le serveur ; la quarantaine au lieu de la suppression ; la liste est reconstruite chaque jour, et ce qui n’est plus signalé en sort. Les personnes concernées ne peuvent pas voir la liste et ne disposent d’aucune voie propre pour exiger un retrait, si ce n’est en passant par nous.

Vraisemblance – possible. Gravité – limitée, car rien n’est perdu et le destinataire peut libérer le message. Niveau – faible à moyen. Avec les réseaux IP activés, des réseaux de fournisseurs entiers seraient concernés, les adresses IP sont des données à caractère personnel, et la gravité passerait à importante : élevé.

R12 – Rapports et captures d’écran sous un lien public

Les rapports de la vérification gratuite, de la vérification de prospects et des vérifications de domaines Clients sont accessibles sans connexion sous un lien aléatoire. Le lien contient 128 bits d’aléa et ne peut pas être deviné (cfg/check_lib.php). Les pages portent noindex, l’application envoie une politique de référent qui ne transmet que l’origine (www/.htaccess), et les captures d’écran ne sont fournies qu’avec le rapport auquel elles appartiennent ; un autre numéro d’image renvoie « introuvable » (www/shot.php). Le risque n’est pas cryptographique mais humain : un lien est transmis, copié dans un ticket, partagé dans un chat. Qui l’ouvre n’est consigné que dans le journal des pages vues comme toute consultation de page (60 jours), dans lequel le lien lui-même n’apparaît que sous forme masquée ; il n’existe pas de liste des lecteurs par rapport.

Vraisemblance – possible. Gravité – limitée, car le rapport ne montre que des informations publiques et expire respectivement après 30 ou 90 jours ; les rapports sur les domaines Clients restent accessibles tant que la vérification existe (13 mois, la dernière plus longtemps). Niveau – faible.

R13 – Faiblesses de l’infrastructure

Les points suivants figurent comme ouverts dans notre dossier d’examen interne et ne sont pas enjolivés ici. Nous les décrivons aussi précisément que les Clients en ont besoin pour leur propre analyse, mais pas au point que la description montre le chemin à un attaquant ; nous communiquerons les détails à une autorité de contrôle sur demande.

Les sauvegardes de la base de données sont actuellement stocké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 (cfg/backup_lib.php). D’ici là, elles ne protègent pas contre la perte du site, et quiconque obtient la base de données obtient aussi les sauvegardes. Les identifiants pour l’analyse derrière la connexion n’y figurent que sous forme chiffrée.
Aucun chiffrement de la base de données au repos. Font exception les champs chiffrés individuellement (identifiants des comptes de test, secret du second facteur).
Les connexions au sein de notre réseau interne ne sont pas chiffrées de bout en bout.
Administration des serveurs. La sécurité de l’accès administratif à nos serveurs n’atteint pas encore le niveau que nous visons pour l’exploitation ; le renforcement de l’administration des serveurs se poursuit.
Environnement de vérification. Le serveur d’analyse ouvre des sites web de tiers dans un navigateur. Les conteneurs de vérification sont isolés – réseau propre, aucun privilège particulier, lecture seule, limités (scanner/src/worker.js). La séparation entre l’environnement de vérification et les autres parties du service est en cours de renforcement (section 9.3).

Vraisemblance – possible. Gravité – grave, car en cas d’incident, tout serait touché en même temps. Niveau – élevé. Il peut être remédié aux différents points par des moyens ordinaires (section 9.3).

R14 – Droits des personnes concernées pour des personnes qui ne nous connaissent pas

Quiconque apparaît incidemment sur une capture d’écran ou dont le message a transité par une copie de contrôle ignore généralement notre existence. Même s’il la connaît, il ne dispose d’aucune clé vers « ses » données : nous ne les enregistrons pas par personne, mais par domaine et par vérification. Nous ne pouvons répondre à une demande d’accès au titre de l’Art. 15 que si la personne indique le domaine ; nous pouvons alors parcourir les vérifications et images existantes. Pour les véritables messages de visiteurs, il n’y a rien à communiquer, car nous ne les enregistrons pas – à l’exception du domaine de l’expéditeur mentionné en R1. L’opt-out ne fonctionne que pour les exploitants d’un domaine, et non pour les personnes représentées ; pour elles, reste la voie de contact@lukaswojcik.com.

Vraisemblance – probable en tant que situation structurelle. Gravité – limitée, car les données sont de courte durée et ne sont pas organisées par personne. Niveau – faible.

9. (d) Mesures envisagées pour faire face aux risques

Chaque mesure porte un statut, et les statuts ne sont pas décoratifs. Mise en œuvre aujourd’hui – vérifiée signifie : lue dans le code du système de développement et, dans la mesure du possible, mesurée par rapport à la base de données. Partielle signifie : le mécanisme existe mais n’atteint pas encore pleinement son objectif. Prévue signifie : proposée par la présente analyse et non développée ; le propriétaire décide si et quand. Restant à définir désigne des procédures et des décisions qu’aucun code ne remplace. Une AIPD qui présente des mesures prévues comme mises en œuvre perd sa valeur précisément dans la situation où l’on en a besoin.

9.1 Mises en œuvre aujourd’hui – vérifiées

Mesure	Risques traités	Référence source
Le robot d’exploration lit le robots.txt avant chaque vérification ; une exclusion couvrant la page d’accueil, un robots.txt inaccessible ou une erreur de serveur met fin à la vérification (les sous-chemins ne sont pas respectés individuellement ; le pouls, la récupération de la preuve, l’outil d’en-têtes et la recherche de fichiers ne le lisent pas)	R5, licéité	`scanner/src/net.js`
Opt-out sans preuve, effectif immédiatement, pour le domaine et sa variante www, pour les vérifications anonymes, les prospects, les études et les vérifications de Clients (la surveillance en cours prend fin à la prochaine vérification planifiée) ; vérifié deux fois (application et service de vérification) ; levé uniquement par nous sur demande et sur preuve	R5, R7, Art. 21	`cfg/check_lib.php` ; `cfg/akquise_lib.php` ; `cfg/studie_lib.php` ; `scanner/src/worker.js`
Vérification gratuite : arrêt d’urgence, reCAPTCHA, une vérification par domaine et par semaine, limites par adresse IP et par session, plafond quotidien, aucun domaine récent, uniquement des adresses publiques, note et signal sans contenu en cas d’anomalie	R5	`cfg/check_lib.php`
Pour les limites, la session n’est enregistrée que sous forme de valeur de hachage, jamais l’identifiant de session	Minimisation	`cfg/check_lib.php`
Aucune valeur de champ (le début des champs cachés et des attributs data n’est lu que pendant la vérification, section 6.2) ; adresses des destinataires uniquement sous forme de domaine ; identifiants de compte masqués dans les adresses de scripts	Minimisation	`scanner/src/crawl.js`
Le rapport gratuit est un extrait : uniquement les constats de base, pas de preuves de tous les détecteurs	R5	`cfg/check_lib.php`, `FE_FREE_DETEKTOREN`
Rapports sous un lien aléatoire de 128 bits, `noindex`, images uniquement pour leur propre rapport, en dehors du répertoire web public ; le lien n’apparaît dans le journal des pages vues que sous forme masquée	R12	`cfg/check_lib.php` ; `www/report.php` ; `www/shot.php`
Suppression : rapports anonymes après 30 jours, prospects après 90 jours, vérifications de Clients après 13 mois (la dernière par domaine est conservée tant que le domaine existe), les données d’un domaine supprimé immédiatement (pour les exceptions, voir la section 6.11), les images étant chaque fois supprimées avec elles	Limitation de la conservation	`cfg/check_lib.php` ; `cfg/fristen_lib.php`
Étude : publication uniquement sous forme de total, segments uniquement à partir de 20 sites web disposant d’un formulaire, données brutes supprimées lors de la publication	R4 en partie, P3	`cfg/studie_lib.php`
Conteneurs de vérification : réseau isolé propre, aucun privilège particulier, lecture seule, limites de mémoire et de processus, limite de temps ; filtre contre les destinations privées pour chaque requête, service workers bloqués et connexions WebSocket fermées afin que rien ne contourne le filtre ; requêtes du serveur web uniquement sur les ports web et uniquement vers l’adresse publique exacte vérifiée au préalable	R13	`scanner/src/worker.js` ; `scanner/src/net.js`
Vérification active pour les Clients uniquement pour un domaine vérifié (en interne également pour nos propres domaines de test et de démonstration) et avec l’arrêt d’urgence activé, vérifié deux fois ; au maximum cinq soumissions ; uniquement des formulaires de contact clairement reconnus sans données personnelles obligatoires ; aucun domaine d’autorités publiques, d’établissements d’enseignement, de cliniques, de cabinets médicaux, de la police ou des tribunaux ; le modèle de langage ne peut rien autoriser ; message de test sans données à caractère personnel, marqué, avec un renvoi à la page du robot d’exploration et à l’opt-out	R9	`scanner/src/worker.js` ; `scanner/src/classify.js` ; `scanner/src/active.js`
Parcours de navigateur : uniquement GET et HEAD, adresses dangereuses bloquées, les valeurs fictives ne quittent pas le navigateur, images avec champs de saisie noircis	R3 (pour ces images), R9	`scanner/src/browser.js`
Vérification des fichiers : uniquement les domaines vérifiés, une récupération par chemin, au maximum 8 Ko, contenu jamais enregistré	R9	`cfg/dateien_lib.php`
Seconde sonde : désactivée par défaut ; ne recevrait qu’une liste fixe d’éléments inoffensifs, signée	Destinataires	`cfg/formular_probe_lib.php`
Analyse derrière la connexion : uniquement un domaine vérifié, offre payante, propriétaire ou administrateur, confirmation « compte de test » ; chiffrement avec la clé publique du serveur d’analyse, lié au domaine ; identifiants jamais affichés, journalisés ni restitués via l’API ; transmission uniquement via l’entrée standard ; champ de la tâche effacé immédiatement, restes après une heure ; aucune capture d’écran, aucune soumission, aucune adresse de déconnexion ou de suppression, interruption en cas de CAPTCHA ; suppression définitive avec écrasement	R8	`cfg/login_lib.php` ; `scanner/src/login.js` ; `scanner/src/geheim.js` ; `scanner/src/worker.js`
Contrôle de livraison : désactivé par défaut ; la récupération ne lit que les en-têtes et 8 Ko, sans marque de lecture ; contenu et adresse du visiteur jamais dans la base de données ; chaque e-mail récupéré est supprimé, y compris ceux qui ne peuvent être attribués ; correspondances supprimées après 180 jours ; preuve uniquement via la copie de ce test précis	R1, R2	`cfg/zustellung_lib.php`
Protection en essaim : uniquement des domaines, réseaux IP désactivés ; seuils minimaux ; exceptions pour les grands services et les domaines des Clients ; quarantaine au lieu de suppression ; liste reconstruite chaque jour ; signalements supprimés après 30 jours	R11	`cfg/swarm_lib.php`
Modèle de langage sur notre propre serveur, sans droit de soumission	R10	`scanner/src/classify.js`
Les signaux via Telegram ne contiennent qu’une phrase fixe sans variables	Destinataires	`cfg/check_lib.php`
Test hebdomadaire de restauration de la sauvegarde, avec alerte en cas d’échec	Disponibilité	`cfg/backup_lib.php` ; `srv/cron_status.php`

9.2 Partielles – en place, mais n’atteignant pas encore leur objectif

Mesure	Pourquoi elle n’est pas encore pleinement efficace
Captures d’écran « nettoyées »	Seules les images des parcours de navigateur sont noircies. Les images du robot d’exploration – page d’accueil et éléments de formulaire – et l’image de la page de réponse d’une vérification active ne le sont pas (R3).
Durées applicables aux données de vérification	Effectives pour les vérifications anonymes, de prospects et de Clients ; pas pour les vérifications internes et les études non publiées ; notes d’anomalie non résolues sans limite de durée (R4).
Suppression des copies de contrôle	Effective dans notre vue de la boîte aux lettres. Si la passe s’interrompt, des e-mails restent ; ce que le fournisseur de la boîte aux lettres conserve dans ses propres sauvegardes n’a pas été vérifié (R2).
Protection des identifiants dans l’analyse derrière la connexion	Forte au repos et dans le service de vérification ; pas sur le chemin vers le site web : `http` est autorisé, les erreurs de certificat sont ignorées (R8).
Preuve de contrôle	Est vérifiée une seule fois puis vaut indéfiniment ; le nom d’hôte d’un domaine disposant d’une preuve de contrôle ne peut toutefois pas être modifié, de sorte que la preuve ne passe pas à un autre hôte (R7).
Information des personnes concernées	En place pour les exploitants via la page du robot d’exploration, l’identifiant, la Politique de confidentialité et l’opt-out ; pour les visiteurs dans le contrôle de livraison, tributaire de la reprise du bloc de texte par le Client ; l’application ne le vérifie pas.
Demande aux Clients de ne pas faire figurer de catégories particulières dans la copie de contrôle	Énoncée dans les documents juridiques, mais non soutenue techniquement : lors de la configuration, l’application ne demande pas le type de site web et n’avertit pas pour les domaines évoquant la santé, le droit ou l’éducation (R1).

9.3 Prévues – non mises en œuvre

Mesure	Risques traités	Priorité
Voie de suppression pour les vérifications internes : supprimer les vérifications sans domaine ni rapport après une durée fixe (proposition : 30 jours) ; supprimer les données brutes d’une étude au plus tard une durée fixe après son achèvement, même sans publication (proposition : 90 jours) ; supprimer une fois les 85 vérifications existantes avec 369 images	R4	En premier
N’activer le contrôle de livraison qu’une fois le contrat avec le fournisseur de la boîte aux lettres conclu, les lieux de stockage, sous-traitants ultérieurs et durées de sauvegarde documentés, le mécanisme de transfert pour le fournisseur de la boîte aux lettres clarifié et les enregistrements MX de notre domaine pointant directement vers la boîte aux lettres ; d’ici là, maintenir la fonction bloquée sur le système de production	R2	En premier
Vérifier la sécurité de la récupération de la boîte aux lettres sur le système de production et la documenter avant l’activation du contrôle de livraison	R2	En premier
Analyse derrière la connexion uniquement via `https` et avec un certificat valide ; rejeter les adresses `http` ; erreurs de certificat lors de la connexion comme motif d’interruption	R8	En premier
Ne pas enregistrer les valeurs des champs cachés derrière la connexion (uniquement nom, type et longueur) – déjà mis en œuvre ainsi, pas d’étape supplémentaire	R8	Fait
Limiter la copie de contrôle aux messages de test lorsque le plugin ou l’extension est utilisé : copie cachée uniquement pour les soumissions portant notre identifiant de test	R1	Élevée
Ne pas enregistrer le domaine de l’expéditeur des véritables messages ni l’inscrire dans les alertes s’il n’est ni le domaine du site web ni celui d’un service d’envoi connu ; dans l’alerte, indiquer à la place « domaine d’expéditeur étranger »	R1	Élevée
Avertissement lors de la configuration du contrôle de livraison pour les domaines évoquant la santé, le droit, les services sociaux ou l’éducation, avec un renvoi à l’AIPD propre du Client	R1	Élevée
Renouveler régulièrement la preuve de contrôle (proposition : avant chaque vérification active, vérifier si l’enregistrement DNS, la balise meta, le fichier ou la connexion du plugin existe toujours ; sinon, poursuivre en mode passif et informer le Client)	R7	Élevée
Cesser de photographier la page d’accueil, ou seulement avec images et visages noircis ; limiter les images de formulaire à l’élément de formulaire (comme aujourd’hui) et masquer les champs de saisie comme pour les parcours de navigateur	R3	Élevée
Avertissement dans l’interface de la vérification de prospects : l’envoi non sollicité du constat succinct par e-mail ou par téléphone constitue de la prospection directe, même entre entreprises, et requiert un consentement préalable (Art. 398 de la loi polonaise sur les communications électroniques ; en Allemagne § 7(2) UWG, le consentement présumé suffisant toutefois pour les appels à des entreprises)	R6	Élevée
Infrastructure : achever le renforcement de l’administration des serveurs ; copie chiffrée de la sauvegarde sur un second site ; chiffrer de bout en bout les connexions du réseau interne ; renforcer encore la séparation entre le serveur d’analyse et l’application	R13	Élevée
Durée pour les notes d’anomalie non résolues (proposition : résolution dans les 30 jours, sinon suppression de l’adresse IP)	R4	Moyenne
Une page ou un formulaire permettant de demander le retrait d’un domaine de la protection en essaim	R11, R14	Moyenne
Avant l’activation des réseaux IP dans la protection en essaim : une nouvelle version de la présente analyse	R11	Condition
Établir si le logiciel du modèle de langage enregistre les requêtes et, le cas échéant, désactiver ces journaux	R10	Faible

9.4 Procédures et décisions restant à définir

Outre les garanties techniques, l’Art. 35(7)(d) exige également des procédures. Celles-ci sont encore en suspens :

Violation de données à caractère personnel. Détection : le propriétaire, l’alerte d’erreur de l’application, les signalements via le point de signalement des vulnérabilités ou contact@lukaswojcik.com. Décision sur la notification à l’UODO dans les 72 heures (Art. 33(1)) : le propriétaire. Information des Clients concernés en tant que responsables du traitement : dans les meilleurs délais, si possible dans les 48 heures, comme promis dans le Contrat de sous-traitance. À définir : une description écrite de la procédure et un premier exercice ; pour le contrôle de livraison, en outre, la manière d’établir quels Clients sont concernés par une violation chez le fournisseur de la boîte aux lettres.
Secteurs. À définir : si le contrôle de livraison est proposé, proposé avec un avertissement ou exclu pour les sites web des secteurs de la santé, du droit, des services sociaux et de l’éducation.
Vérifications internes. À définir : à quelles fins le fournisseur utilise les vérifications internes en ligne de commande, qui peut les créer et combien de temps leurs résultats sont conservés ; et si, au-delà du Registre des activités de traitement, elles doivent être mentionnées dans la Politique de confidentialité.
Études. À définir : qui établit les listes, à partir de quelles sources, avec quelle taille maximale, et une vérification avant chaque étude de sa conformité aux hypothèses de la présente analyse.
Avis des personnes concernées (Art. 35(9)). Ils n’ont pas été demandés pour la présente version. L’Art. 35(9) n’impose de les demander que « le cas échéant » ; selon notre appréciation, ce n’est actuellement pas le cas ici. Les exploitants des sites web vérifiés et les visiteurs des sites web des Clients ne disposent d’aucun canal propre vers nous ; s’adresser à eux de manière ciblée constituerait en soi un nouveau traitement de leurs données, et le service n’a pas encore été lancé, de sorte qu’il n’existe pas encore de groupe de personnes effectivement concernées. Leurs intérêts sont pris en compte indirectement : par le robots.txt et l’opt-out, par les durées courtes et par le fait que le contenu des copies de contrôle n’est pas enregistré. À chaque réexamen au titre de la section 12, nous réexaminons s’il est opportun de demander leur avis, par exemple via des retours sur la page du robot d’exploration ou auprès des Clients du contrôle de livraison.

10. Risque résiduel et consultation préalable au titre de l’Art. 36

L’Art. 36(1) impose la consultation préalable de l’autorité de contrôle lorsque l’AIPD indique que le traitement présenterait un risque élevé si le responsable du traitement ne prenait pas de mesures pour atténuer le risque. La question n’est donc pas de savoir si des risques élevés ont été identifiés – quatre l’ont été – mais si un risque élevé subsiste une fois les mesures en place.

Pour les opérations de traitement dont formexposed est le responsable (P1 à P4, P7), il peut être remédié aux risques élevés R4 et R13 par des moyens ordinaires : une voie de suppression et un nettoyage des données existantes, une sauvegarde chiffrée hors site et le renforcement de deux serveurs. Avec les mesures de la section 9.3, ils descendent à faible à moyen. R3, R5, R6 et R7 sont au niveau moyen et descendent à faible avec les mesures proposées. La protection en essaim sans réseaux IP reste faible à moyenne. La consultation préalable n’est pas nécessaire pour cette partie si les mesures marquées « en premier » et « élevée » sont mises en œuvre avant le lancement. Si l’une de ces mesures n’a pas été mise en œuvre avant le lancement, un risque élevé subsiste pour l’opération de traitement concernée. Cette opération ne sera alors lancée qu’une fois la mesure mise en œuvre, ou l’UODO sera d’abord consulté au titre de l’Art. 36(1).

Pour le contrôle de livraison (P6), la situation est différente, pour une raison qu’aucune mesure ne supprime entièrement : ce qu’un visiteur écrit lui appartient. Avec un contrat conclu, une récupération sécurisée, une limitation aux messages de test lorsque c’est possible et la renonciation au domaine de l’expéditeur, R2 descend à faible et R1 à moyen. Pour les Clients dont les visiteurs fournissent typiquement des données au sens de l’Art. 9, R1 peut néanmoins rester élevé. L’obligation de consultation incombe alors au Client en tant que responsable du traitement, et non à formexposed. Notre recommandation à ces Clients est de ne pas configurer la copie de contrôle pour le formulaire de contact général, mais uniquement pour des formulaires sans contenu sensible, ou de renoncer au contrôle de livraison.

Le risque résiduel, honnêtement exposé. Aujourd’hui, avec les mesures de la section 9.1, quatre risques sont au niveau élevé : R1 et R2 (contrôle de livraison), R4 (données de vérification sans voie de suppression) et R13 (infrastructure). Avec les mesures de la section 9.3, R2, R4 et R13 descendent à faible à moyen. R1 reste au niveau moyen et dépend durablement de décisions prises par les Clients. Aucun des autres risques ne dépasse le niveau moyen après les mesures.

L’Art. 36 n’est pas une sanction, et consulter n’est pas un aveu. C’est la voie que le Règlement prévoit pour la situation dans laquelle une procédure utile comporte un risque que le responsable du traitement ne maîtrise pas entièrement. Un Client qui souhaite utiliser le contrôle de livraison pour des messages contenant des données de santé trouvera ici les faits nécessaires à cette décision.

11. Ce dont les Clients ont besoin pour leur propre AIPD (Art. 28(3)(f))

Pour le contrôle de livraison et l’analyse derrière la connexion, le Client est le responsable du traitement. Cette page lui fournit la description (sections 6.5 et 6.6), les risques de notre point de vue (R1, R2, R8) et l’état des mesures (section 9). Seul le Client peut répondre aux questions suivantes :

Qu’écrivent mes visiteurs ? Faut-il s’attendre à ce que des données relatives à la santé, à la religion, à l’origine, à l’appartenance syndicale, à l’orientation sexuelle, à des infractions pénales ou concernant des enfants arrivent via le formulaire ? Une AIPD pour la copie de contrôle est alors en règle générale requise, et la copie de contrôle pour ce formulaire devrait être reconsidérée.
Ai-je besoin de la copie de contrôle pour tous les messages ? Pour prouver que notre message de test arrive, elle suffit pour ce message. Lorsque le formulaire le permet, ne configurez la copie cachée que pour les messages de test.
Comment informer mes visiteurs ? Le Contrat de sous-traitance l’exige ; le Texte de politique de confidentialité pour votre site web décrit le chemin de la copie et notre rôle.
De quelle base juridique est-ce que je dispose ? Notre proposition de texte cite l’Art. 6(1)(f) (réception fiable des demandes). Pour les données au sens de l’Art. 9, cette base ne suffit pas à elle seule.
Quels canaux d’alerte choisir ? Les alertes du contrôle d’authenticité peuvent nommer le domaine de l’expéditeur. Quiconque envoie des alertes vers des services de chat situés hors de l’UE l’y transfère.
Pour l’analyse derrière la connexion : le compte de test est-il réellement un compte de test disposant du minimum de droits nécessaires ? La page de connexion n’est-elle accessible que via https ? Le compte de test voit-il des données d’autres utilisateurs ? Si oui : sur lesquelles des pages désignées ?
Quand supprimer ? Le contrôle de livraison et le compte de test peuvent être désactivés et supprimés à tout moment ; le compte de test est alors définitivement écrasé.

Autres documents pour l’analyse du Client : le Contrat de sous-traitance, les mesures techniques et organisationnelles, la liste des sous-traitants ultérieurs et le Registre des activités de traitement. Nous répondons aux questions sur des faits particuliers à l’adresse contact@lukaswojcik.com.

12. Réexamen, version et approbation

L’Art. 35(11) exige un réexamen afin d’évaluer si le traitement est effectué conformément à l’AIPD, au moins quand il se produit une modification du risque. Nous réexaminons la présente analyse au moins une fois par an ainsi qu’avant chacun des événements suivants ; chacun déclenche une nouvelle mesure, et pas seulement une relecture :

lancement de l’exploitation en production, avec des chiffres issus du système de production au lieu du système de développement ;
première activation du contrôle de livraison sur le système de production et conclusion du contrat avec le fournisseur de la boîte aux lettres ;
activation des réseaux IP dans la protection en essaim ;
la première étude, et chaque étude portant sur une liste plus grande que la précédente ;
activation de la seconde sonde ou d’un nouveau destinataire dans le chemin de vérification ;
toute nouvelle utilisation du modèle de langage allant au-delà de la classification des formulaires et de « Fix it for me » ;
toute modification des captures d’écran, des durées ou des conditions préalables aux vérifications actives.

Élément	Mention
Responsable du traitement	LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Pologne · NIP 7252266190 · contact@lukaswojcik.com
Autorité de contrôle compétente	Prezes Urzędu Ochrony Danych Osobowych (UODO), ul. Moniuszki 1A, 00-014 Warszawa, Pologne
Délégué à la protection des données	Non désigné ; appréciation au titre de l’Art. 37 à la section 4
Base des faits	Code source de l’application et du service de vérification, schéma de la base de données, nombres de lignes et paramètres du système de développement, mesurés le 11 octobre 2026, en lecture seule
Documents connexes	Politique de confidentialité, Contrat de sous-traitance, Mesures techniques et organisationnelles, Sous-traitants ultérieurs, Registre des activités de traitement, Règlement européen sur l’IA, Utilisation acceptable et abus, FormExposedBot, Opt-out
Version	1.0 du 11 octobre 2026, première version
Réexamens au titre de l’Art. 35(11)	Aucun à ce jour (première version). Chaque réexamen est consigné ici avec sa date, son motif et son résultat.
Approbation	Pas encore approuvée. Approbation par le propriétaire après examen juridique et après décision sur les mesures de la section 9.3 et les questions de la section 9.4. Aucun conseil externe en protection des données n’a été sollicité à ce jour.

Une dernière observation a sa place dans le document et non dans une lettre d’accompagnement. Les parties de formexposed qui empiètent le plus sur le domaine d’autrui – les soumissions de test et la connexion avec les identifiants d’un tiers – sont conçues avec la plus grande prudence : deux verrous, des plafonds stricts, un chiffrement qui nous exclut nous-mêmes. Les risques de la présente analyse se situent pour l’essentiel ailleurs : dans ce qui vient incidemment – de véritables messages dans une copie cachée, des personnes sur une capture d’écran, des vérifications que plus personne ne supprime. C’est une situation de départ favorable, car l’incident peut être arrêté sans modifier le service.

Comment pouvons-nous vous aider ?