formexposed
Commencer

Mesures techniques et organisationnelles

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

Version 1.1 · Dernière mise à jour : 22 octobre 2026

Mesures au titre de l’Art. 32 RGPD par lesquelles LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Pologne, protège le service formexposed. Cette page fait partie intégrante du contrat de sous-traitance en tant qu’Annexe 2.

1. Champ d’application et principe

Les mesures s’appliquent à toutes les données traitées par le service : aux données que nous traitons pour le compte de nos Clients (décrites dans le contrat de sous-traitance) et aux données dont nous sommes nous-mêmes responsables du traitement, comme les comptes clients et les journaux. Il n’existe pas de niveaux de protection distincts pour les deux ; ce qui protège le compte protège aussi les données traitées en tant que sous-traitant.

Structure au regard de l’Art. 32(1) RGPD. La pseudonymisation et le chiffrement (point (a)) sont traités à la section 4 ; la confidentialité, l’intégrité, la disponibilité et la résilience constantes des systèmes (point (b)) aux sections 3, 5, 6 et 7 ; la capacité à rétablir la disponibilité dans des délais appropriés en cas d’incident (point (c)) à la section 7.1 ; la procédure visant à tester, à analyser et à évaluer régulièrement l’efficacité (point (d)) à la section 9. Nous avons choisi les mesures sur la base des risques décrits dans notre Analyse d’impact relative à la protection des données, en tenant compte de l’état des connaissances et des coûts de mise en œuvre.

Principe : mesuré plutôt que voulu. Seul ce qui a effectivement été mis en œuvre dans le code ou dans l’exploitation est indiqué ici. Ce qui est prévu mais pas encore mis en œuvre est expressément listé comme « prévu » à la section 10. Une mesure qui ne figure pas ici n’est pas tacitement en place.

Les noms des machines, les adresses internes, les ports, les noms d’utilisateur et les versions de logiciels ne sont volontairement pas indiqués. Ils n’aident personne à évaluer les mesures, mais ils aident celui qui veut les contourner. Quiconque en a besoin pour un audit au titre du contrat de sous-traitance les recevra dans le cadre de cet audit, sous le sceau de la confidentialité, dans la mesure où ils sont nécessaires à l’audit.

2. Structure du service

Le service fonctionne sur deux serveurs propres du fournisseur en Pologne, situés dans le même réseau interne :

  • Serveur web avec base de données. Il fournit l’application, héberge la base de données, envoie les notifications et sauvegarde les données. Il est le seul configuré pour accepter des requêtes provenant d’internet.
  • Serveur d’analyse. Il effectue les vérifications des sites web de tiers et des sites propres dans un navigateur et exécute le modèle de langage qui classe certains formulaires et ajoute du code dans « Fix it for me ». Il n’est pas configuré pour accepter des requêtes provenant d’internet, mais récupère lui-même ses tâches sur le serveur web et y renvoie les résultats.

Aucun hébergeur, centre de données ni fournisseur de cloud n’intervient dans l’exploitation, et rien n’est envoyé à un service d’IA externe. Les tiers qui reçoivent des données sont indiqués sur la page Sous-traitants ultérieurs.

3. Confidentialité

3.1 Contrôle de l’accès physique

Les serveurs sont situés dans des locaux du fournisseur en Pologne qui ne sont pas ouverts au public. Seul le propriétaire y a accès (selon les déclarations de l’exploitant). L’adresse exacte de l’emplacement n’est volontairement pas indiquée ici.

3.2 Contrôle d’accès : connexion au service

  • Les mots de passe ne sont enregistrés que sous forme de hachage selon la méthode standard de PHP (bcrypt). Si la méthode standard change, le hachage est renouvelé lors de la connexion suivante. Pour une tentative de connexion avec une adresse inconnue, le serveur calcule tout de même un hachage, afin que le temps de réponse ne révèle pas si un compte existe. De même, la réponse à une demande de réinitialisation du mot de passe ne révèle ni par sa formulation ni par sa durée si le compte existe ; les e-mails de réinitialisation sont envoyés à une même adresse au maximum trois fois par heure. Les nouveaux mots de passe doivent comporter au moins dix caractères et ne peuvent dépasser 72 octets (UTF-8), car bcrypt ne prend pas en compte davantage d’octets. La modification du mot de passe déconnecte tous les autres appareils ; sa réinitialisation via le lien déconnecte tous les appareils, et le lien n’est valable qu’une seule fois.
  • Blocage après des tentatives échouées. Les connexions échouées sont comptées par adresse IP ; après un nombre trop élevé en peu de temps (actuellement huit en 15 minutes), la connexion depuis cette adresse est temporairement bloquée. Une connexion réussie remet ce compteur à zéro. Les tentatives sont supprimées après sept jours. En outre, avant chaque vérification de mot de passe, une tentative est comptée par compte (pour une adresse inconnue, par adresse saisie) et par adresse IP, tentatives réussies comprises : actuellement au maximum huit par compte depuis la même adresse IP et 80 par adresse IP en 15 minutes ; une limite nettement plus élevée s’applique par compte toutes adresses confondues, contre les tentatives distribuées. Des tentatives échouées depuis une autre adresse ne peuvent donc plus bloquer le propriétaire hors de son compte. Ces compteurs ne contiennent qu’une clé HMAC, aucune adresse e-mail ou IP en clair, et expirent avec leur fenêtre de temps. Si le stockage des compteurs est indisponible, la connexion est refusée, et non laissée passer. Le même type de limite s’applique à la confirmation du mot de passe avant un changement de mot de passe ou d’adresse, à l’activation ou la désactivation du second facteur, au transfert d’un espace de travail, à l’export de données et à la suppression du compte (cinq tentatives par compte en 15 minutes), aux inscriptions (dix par adresse IP et par heure) et aux mots de passe des portails clients (dix tentatives par portail et par adresse IP, 50 par portail en 15 minutes).
  • Second facteur. Chaque compte peut activer la connexion avec un code à usage unique conforme à la RFC 6238 (TOTP). Le secret correspondant est enregistré chiffré dans la base de données ; la clé n’est pas enregistrée dans la base de données, de sorte qu’un extrait de la base de données ne suffit pas à lui seul. Un code accepté n’est pas valable une seconde fois. Dix codes de récupération sont enregistrés uniquement sous forme de hachage. Les codes à usage unique et de récupération sont limités à dix tentatives par compte en 15 minutes, y compris lors de la configuration.
  • Espace d’administration uniquement avec un second facteur. L’espace d’administration de l’exploitant ne s’ouvre qu’aux comptes dont le second facteur est activé. La liste de contrôle de configuration signale tout compte administrateur sans second facteur.
  • Sessions. Le cookie de session ne peut pas être lu par des scripts (HttpOnly), n’est envoyé que via HTTPS (Secure) et n’est pas envoyé avec les requêtes provenant de sites tiers susceptibles de modifier quelque chose (SameSite=Lax). Lors de la connexion, un nouvel identifiant de session est créé, de sorte qu’un identifiant implanté au préalable n’est plus valable ; le serveur n’accepte pas d’identifiant de session qu’il n’a pas lui-même émis. Chaque compte voit ses appareils connectés et peut les déconnecter individuellement.
  • « Rester connecté » est facultatif et valable 30 jours, mais pas pour les comptes disposant de droits d’administration ; ceux-ci se connectent toujours avec mot de passe et second facteur. Le jeton se compose de deux parties ; la partie de vérification n’est enregistrée dans la base de données que sous forme de hachage. Chaque utilisation le remplace par un nouveau, et même en cas de requêtes simultanées, chaque jeton n’est valable qu’une seule fois, de sorte qu’un jeton volé est détecté au plus tard lors de la visite authentique suivante.
  • Liens dans les e-mails. Les liens de confirmation de l’adresse et de réinitialisation du mot de passe ne sont enregistrés dans la base de données que sous forme de hachage. Le lien de réinitialisation est valable une heure, le lien de confirmation d’une inscription 72 heures, le lien de confirmation d’une adresse modifiée 24 heures. Si l’adresse e-mail est modifiée, un lien de réinitialisation en cours devient invalide.
  • Interfaces. Les clés API, les codes de connexion des extensions et les codes de déploiement ne sont enregistrés que sous forme de hachage. Les clés API ne peuvent être utilisées qu’un nombre limité de fois par minute ; les codes de connexion des extensions sont valables 15 minutes et une seule fois.
  • Protection contre les bots sur les formulaires publics (inscription, connexion, mot de passe, vérification, outil d’en-têtes, opt-out, assistance et contact) : Google reCAPTCHA, qui n’est chargé qu’au moment de l’envoi. Seule une réponse valide de Google avec un score suffisant pour exactement l’action du formulaire est acceptée ; si Google ne répond pas dans les trois secondes, l’envoi est refusé. Les détails figurent dans la Politique de confidentialité.

3.3 Contrôle d’accès : administration des serveurs

  • Le serveur accessible depuis internet utilise un filtre de paquets pour n’autoriser que les services qu’il propose, et bloque automatiquement les adresses après des échecs répétés de connexion à l’administration du serveur.
  • Les processus automatisés entre les serveurs utilisent leurs propres clés avec des droits strictement limités. La clé avec laquelle le serveur web livre les nouvelles versions du scanner ne peut exécuter qu’une liste fixe de commandes sur le serveur d’analyse et ne peut copier, en écriture seule, que dans le répertoire du scanner ; une connexion interactive n’est pas possible avec elle, et toute commande refusée est journalisée. De même, le serveur d’analyse ne peut écrire des captures d’écran que dans un répertoire déterminé du serveur web.
  • Le processus qui sert le site web n’a ni accès en écriture à l’installation de production ni clé pour le serveur d’analyse. Un déploiement déclenché dans l’espace d’administration ne fait que déposer une tâche, qu’un traitement distinct exécute.
  • Les secrets tels que les identifiants de la base de données et les clés sont conservés dans des fichiers de configuration situés en dehors du répertoire servi et ne sont pas copiés lors du déploiement. La configuration du serveur web n’est pas distribuée via l’interface web.

3.4 Contrôle des autorisations : droits au sein du service

  • Rôles. Chaque espace de travail comporte les rôles propriétaire, administrateur et lecteur. La modification, la suppression, l’invitation et l’enregistrement d’identifiants sont réservés aux propriétaires et administrateurs ; seul le propriétaire peut modifier les rôles et retirer des membres. Une invitation n’est valable que tant que la personne qui l’a envoyée est encore propriétaire ou administrateur. Les lecteurs ne voient les adresses des webhooks et des canaux de messagerie que raccourcies à l’hôte, car l’adresse seule permet de publier dans le canal. Le contrôle a lieu sur le serveur, et pas seulement dans l’interface.
  • Rattachement à l’espace de travail. Les domaines et les paramètres ne sont accessibles qu’aux membres de l’espace de travail. Pour chaque vérification, le Service crée un rapport sous un lien aléatoire impossible à deviner ; les résultats et captures d’écran d’une vérification sont accessibles via ce lien sans connexion, les captures d’écran uniquement avec le lien de leur rapport. Le lien apparaît dans le compte et dans les alertes ; quiconque le transmet transmet le rapport.
  • Les requêtes modifiant l’état requièrent un jeton de sécurité par session (protection CSRF), comparé en temps constant.
  • « Voir en tant que client ». Pour l’assistance, l’exploitant peut voir l’application telle qu’un Client la voit. La vue prend fin après une heure, bloque les modifications du mot de passe, de l’adresse, du second facteur, des appareils, de l’abonnement, de l’export et de la suppression, ferme l’espace d’administration pendant ce temps et est journalisée. Y mettre fin déconnecte complètement l’exploitant ; celui-ci ne peut revenir à l’espace d’administration qu’en se reconnectant avec mot de passe et second facteur. Le Client peut la voir dans son export de données.
  • Administration. Seuls quelques comptes expressément autorisés disposent de droits d’administration ; toute réinitialisation d’un second facteur par l’administration est journalisée.

3.5 Contrôle de la séparation

  • Les données des clients sont séparées logiquement par espace de travail. Chaque chemin de lecture et d’écriture dans l’espace connecté porte ce rattachement ; les rapports sont en outre accessibles via leur lien (section 3.4).
  • Le développement et l’exploitation fonctionnent dans des installations distinctes, avec des bases de données distinctes et des utilisateurs de base de données distincts. L’utilisateur de développement n’a pas accès à la base de données de production. Les données réelles des clients ne sont pas copiées dans l’environnement de développement ; nous y travaillons avec des données d’exemple générées.
  • Pour chaque environnement, le scanner dispose de ses propres identifiants, avec des droits limités aux données dont il a besoin pour ses tâches. Il ne peut lire ni les comptes, ni la facturation, ni les journaux.
  • D’autres services du même fournisseur fonctionnent également sur le serveur web. Ils disposent de leurs propres bases de données et de leurs propres utilisateurs de base de données, sans accès aux données de ce service.

4. Chiffrement, pseudonymisation et minimisation des données

4.1 Identifiants pour l’analyse derrière la connexion

Pour cette fonction, le Client enregistre le nom d’utilisateur et le mot de passe d’un compte de test. Ce sont les données les plus sensibles du service, et elles sont donc protégées différemment de tout le reste :

  • Lors de leur enregistrement, le serveur web les chiffre avec la clé publique du serveur d’analyse (ECIES : X25519 avec une clé à usage unique par enregistrement, HKDF-SHA256, AES-256-GCM). La clé privée n’existe que sur le serveur d’analyse. Le serveur web, la base de données et les sauvegardes ne contiennent que le texte chiffré ; nous ne pouvons pas non plus le lire à cet endroit.
  • Chaque enregistrement est lié cryptographiquement à son domaine. S’il est déplacé vers un autre domaine, le déchiffrement échoue.
  • Pour une analyse, le texte chiffré est joint à la tâche. Le serveur d’analyse le déchiffre et ne transmet les identifiants au conteneur de vérification que via l’entrée standard, jamais en argument de ligne de commande qui serait visible dans les listes de processus. Dès que le serveur d’analyse l’a lu, le texte chiffré est supprimé de la tâche ; un traitement efface les éventuels restes au plus tard après une heure.
  • Les identifiants ne sont jamais affichés, jamais journalisés, jamais restitués via l’API et ne sont pas exportés. L’interface n’affiche que le premier caractère et la longueur du nom d’utilisateur. Leur retrait écrase le texte chiffré.
  • Derrière la connexion, le scanner ne fait que lire : aucune soumission, aucun test actif, aucune capture d’écran, aucune page de déconnexion, de suppression ou de résiliation.

4.2 Autres chiffrements et hachages

  • Les mots de passe, codes de récupération, mots de passe des portails clients, clés API, codes de connexion et de déploiement, jetons « Rester connecté », identifiants de session dans la liste des appareils et liens de confirmation et de réinitialisation ne sont enregistrés que sous forme de hachage.
  • Les secrets du second facteur sont enregistrés chiffrés (section 3.2).
  • Nous ne prétendons pas chiffrer l’intégralité de la base de données au repos. Les valeurs sensibles sont protégées individuellement, comme décrit ci-dessus.

4.3 Minimisation des données dès la conception

  • Contrôle de livraison : seuls les en-têtes et au maximum les 8 premiers Ko du texte sont lus. Seuls l’heure, le rattachement, le cas échéant l’identifiant de la soumission de test, et le résultat du contrôle d’authenticité (SPF, DKIM, DMARC) sont enregistrés dans la base de données, jamais le contenu ni une adresse d’expéditeur complète. Le résultat d’authenticité de l’e-mail le plus récent est conservé avec le domaine et écrasé par le suivant ; il contient l’adresse IP du serveur de messagerie expéditeur et le domaine e-mail de l’expéditeur. L’e-mail est supprimé de la boîte aux lettres après un traitement réussi ; si la récupération ou la suppression échoue, cela se fait lors du passage réussi suivant.
  • Vérifications : la structure des formulaires est enregistrée avec les noms de champs, types et libellés, les attributs d’obligation et de visibilité, sans valeurs ; le scanner ne lit les débuts des champs cachés pré-remplis (jusqu’à 24 caractères) et des attributs data (jusqu’à 60 caractères) que pendant la vérification et ne les enregistre pas. Les captures d’écran de la vérification complète ne sont pas caviardées ; seules les vérifications par navigateur masquent les champs de saisie. Les adresses de destinataires des formulaires ne sont enregistrées que sous forme de domaine. Les soumissions de test actives ne contiennent que des textes de test identifiés, sans données à caractère personnel.
  • Les extensions pour WordPress et TYPO3 ne transmettent que des chiffres quotidiens et des caractéristiques telles que l’inventaire des plugins, et pour un plugin WordPress connecté également les domaines des liens issus de messages bloqués pour la protection collective (activée par défaut) ; aucun autre contenu, aucun nom, aucune adresse ni adresse IP de visiteurs. Les décomptes facultatifs d’erreurs de formulaires et de champs sont désactivés par défaut.
  • « Fix it for me » : le code collé n’est traité que pendant la durée de la requête et n’est pas enregistré.
  • Badge : l’image du badge sur les sites web des clients ne dépose aucun cookie et n’ouvre aucune session.
  • Les notifications d’exploitation envoyées au téléphone de l’exploitant sont des textes fixes sans variables, c’est-à-dire sans noms, adresses ni contenus. Les notifications d’erreur envoyées par e-mail à l’exploitant contiennent le texte brut du message d’erreur, non nettoyé et tronqué à 400 caractères ; dans certains cas, il peut contenir des adresses ou des liens.
  • Protection collective : entre les extensions des Clients, seuls les domaines des liens figurant dans des spams bloqués sont partagés ; l’échange de réseaux IP est désactivé.
  • Localisation : le pays d’une adresse IP est déterminé à partir d’un fichier de base de données local ; aucune adresse n’est envoyée à un service de géolocalisation.

5. Protection contre l’utilisation abusive du scanner

Le scanner charge des pages de tiers avec un véritable navigateur. Sans protection, il constituerait un outil permettant à quelqu’un de l’extérieur d’atteindre notre réseau interne ou d’autres cibles non publiques (falsification de requêtes côté serveur). Il existe donc deux couches indépendantes et une isolation de chaque exécution.

5.1 Exécution isolée

  • Chaque vérification s’exécute dans son propre conteneur, qui est supprimé ensuite. Elle s’exécute sans droits d’administrateur, sans capacités supplémentaires du système d’exploitation et sans possibilité d’élévation de privilèges. Son système de fichiers est en lecture seule, à l’exception de petites zones volatiles.
  • La mémoire, le nombre de processus et la durée d’exécution sont limités ; une exécution qui dépasse le temps imparti est interrompue.

5.2 Réseau : deux couches

  • Première couche, dans le scanner : avant l’analyse, puis pour chaque requête du navigateur, y compris les redirections et les contenus intégrés, on vérifie vers quoi l’adresse est résolue. Les réseaux privés, locaux, réservés et de documentation (IPv4 et IPv6) sont rejetés, de même que les ports autres que ceux habituels pour le web. Le navigateur n’autorise pas les service workers, et les connexions WebSocket sont fermées, car les deux pourraient contourner ce contrôle.
  • Seconde couche, dans le réseau : les conteneurs fonctionnent dans leur propre réseau. Des règles de pare-feu n’autorisent depuis ce réseau des connexions vers internet que sur les ports web ; les connexions vers des réseaux privés, y compris notre réseau interne avec le serveur web et la base de données, sont bloquées. Les exceptions requises par l’exécution de la vérification elle-même sont limitées au strict nécessaire et décrites dans notre documentation interne. Cette couche s’applique également si un nom n’est résolu différemment qu’après le premier contrôle.

5.3 Requêtes effectuées par le serveur web

Lorsque le serveur web interroge lui-même des adresses de tiers – pour la preuve de contrôle du domaine, pour l’outil d’en-têtes, pour la recherche de fichiers exposés, pour les requêtes de pouls, pour les requêtes RDAP et la vérification des certificats, pour les webhooks et les alertes de messagerie instantanée et pour le second point de contrôle facultatif – les mêmes règles s’appliquent : protocoles web uniquement, sur les ports web habituels (webhooks et alertes de messagerie instantanée uniquement via HTTPS sur le port standard), adresses publiques uniquement, connexion uniquement à l’adresse exacte vérifiée au préalable, afin qu’un nom ne puisse pas être redirigé ultérieurement vers une cible interne, redirections soit non suivies, soit suivies uniquement manuellement et revérifiées à chaque fois, délais courts ; pour la preuve de contrôle du domaine, pour les requêtes de pouls et pour le second point de contrôle des vérifications par navigateur, également une taille de réponse limitée.

5.4 Ce que le scanner ne fait pas sur les sites de tiers

  • Les soumissions de test actives (au maximum cinq par vérification) n’existent pour les Clients que pour les domaines dont la preuve de contrôle a été apportée (DNS, balise meta, fichier ou extension) ; la seule exception concerne les vérifications internes de nos propres domaines de test et de démonstration. Le nom d’hôte d’un domaine avec preuve de contrôle ne peut pas être modifié, afin que la preuve ne passe pas à un autre hôte. Tout le reste est passif : lecture des pages comme un visiteur.
  • Les vérifications par navigateur vont jusqu’au moment précédant la soumission et ne déclenchent aucune commande, aucun paiement ni aucune soumission.
  • Les domaines figurant sur la liste d’opt-out ne sont pas vérifiés ; la surveillance en cours prend fin avec la prochaine vérification prévue.

6. Intégrité : transfert et saisie

6.1 Transport

  • L’application n’est accessible depuis internet que via HTTPS ; le navigateur reçoit l’instruction de n’utiliser que HTTPS pendant un an (HSTS). Les certificats sont renouvelés automatiquement.
  • D’autres en-têtes limitent l’intégration de l’application dans des pages de tiers, la détection par devinette des types de fichiers et l’envoi de formulaires vers des cibles tierces. Une politique de sécurité du contenu ne laisse s’exécuter dans l’application que les scripts que le serveur autorise avec la réponse concernée ; les navigateurs actuels n’exécutent pas les scripts ou gestionnaires d’événements injectés dans le HTML.
  • La boîte aux lettres du contrôle de livraison est relevée via une connexion chiffrée avec vérification du certificat.
  • Les webhooks peuvent être signés avec un secret du Client (HMAC-SHA256 avec horodatage), afin que le destinataire puisse vérifier l’origine et l’intégrité. Les requêtes vers le second point de contrôle facultatif sont signées, et pour les vérifications par navigateur leurs réponses également.
  • Dit ouvertement : les connexions au sein de notre réseau interne ne sont pas chiffrées de bout en bout. Les identifiants pour l’analyse derrière la connexion restent chiffrés de bout en bout (section 4.1).

6.2 Contrôle de la saisie et journaux

  • Les actions importantes dans les comptes et les espaces de travail (comme la connexion, les modifications des domaines, des destinations d’alerte et des droits, les suppressions, les accès d’assistance) sont consignées dans le journal d’activité avec le compte, l’heure, l’adresse IP et le pays, et supprimées après 365 jours.
  • Les enregistrements d’accès aux pages conservés pour la sécurité et la prévention des abus sont supprimés après 60 jours, les journaux d’erreurs après 90 jours, les contenus des e-mails envoyés après 30 jours. Les jetons d’accès figurant dans les adresses demandées et les référents, comme ceux des liens de rapport ou de portail, n’apparaissent dans les enregistrements d’accès aux pages que sous forme masquée.
  • L’acceptation des documents contractuels est enregistrée avec la version affichée, sa somme de contrôle, l’heure, l’adresse IP et l’identifiant du navigateur.
  • Les journaux de preuve peuvent être munis d’un horodatage émis par une autorité d’horodatage externe ; seule une somme de contrôle du contenu lui est transmise, et non le contenu lui-même.

7. Disponibilité et résilience

7.1 Sauvegarde

  • La base de données est sauvegardée chaque nuit. Une sauvegarde ne reçoit son nom définitif qu’après vérification de son contenu : achèvement réussi du programme de sauvegarde, au moins un enregistrement, autant de tables que la base de données et la ligne finale d’une exécution complète. Les sauvegardes plus anciennes ne sont supprimées qu’après une nouvelle sauvegarde réussie.
  • Chaque sauvegarde est supprimée après 14 jours. L’emplacement de stockage se trouve en dehors de tout répertoire servi ; un emplacement à l’intérieur du projet est refusé.
  • Test de restauration : une fois par semaine, la dernière sauvegarde est chargée dans une base de données jetable, comparée table par table avec la production puis supprimée. Le résultat est enregistré.
  • Si une sauvegarde ou un test échoue, une notification est envoyée par e-mail et sur le téléphone de l’exploitant.
  • Rétablissement après un incident : si la base de données tombe en panne ou si des données sont corrompues, nous restaurons la dernière sauvegarde testée. Les modifications intervenues depuis cette sauvegarde, en règle générale au maximum celles d’une journée, peuvent être perdues ; si une sauvegarde a échoué, davantage en conséquence. Nous réexécutons ensuite les demandes de suppression ultérieures connues (section 8). Nous ne nous engageons sur aucun délai de rétablissement particulier.
  • Limite, dite ouvertement : 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. Elles protègent contre les erreurs d’exploitation, les modifications défectueuses et les données corrompues, mais pas contre la perte du serveur lui-même. Une copie chiffrée sur un second site est prévue (section 10).
  • Les identifiants pour l’analyse derrière la connexion ne figurent dans les sauvegardes que sous forme de texte chiffré ; le secret du second facteur uniquement sous forme chiffrée, avec une clé située en dehors de la base de données.

7.2 Surveillance

  • Un contrôle d’état vérifie toutes les cinq minutes les composants du service, y compris la base de données, la file d’attente et le signal de vie du scanner, que celui-ci écrit régulièrement même au repos. Si un composant tombe en panne, une notification est envoyée ; s’il se rétablit, une levée d’alerte.
  • Surveillance croisée : un contrôle d’état ne peut pas signaler la panne de la machine sur laquelle il s’exécute. Le serveur d’analyse vérifie donc chaque minute si l’application répond et, après plusieurs échecs consécutifs, envoie un texte fixe au téléphone de l’exploitant. Inversement, le serveur web surveille le signal de vie du scanner ; la liste de contrôle de configuration indique si la surveillance croisée fonctionne.
  • Alerte d’erreur : un type d’erreur jamais survenu auparavant est signalé une fois immédiatement ; une accumulation d’erreurs ne déclenche qu’un seul signal sur le téléphone de l’exploitant ; une fois par jour, une vue d’ensemble est envoyée. Ainsi, nous n’apprenons pas une erreur d’abord par un Client.
  • Limite, dite ouvertement : les deux serveurs se trouvent au même emplacement. Une panne de l’ensemble du site, par exemple de l’alimentation électrique ou de la connexion internet, n’est signalée par aucun mécanisme d’alerte mais constatée par un humain.

7.3 Modifications et déploiement

  • Les nouvelles versions sont d’abord construites et testées dans l’environnement de développement distinct. Le déploiement vérifie toutes les conditions préalables avant l’écriture du premier fichier, effectue les modifications du schéma de la base de données et laisse les vérifications en cours se terminer proprement avant le redémarrage du scanner.
  • Pour le parcours d’un nouveau Client, il existe un test de fumée en HTTP réel, exécuté après les basculements. Nous ne prétendons pas disposer d’une suite de tests automatisés avant chaque déploiement.

8. Suppression et durées de conservation

  • Un traitement de suppression nocturne applique les durées indiquées dans la Politique de confidentialité et le contrat de sous-traitance. Il lit les mêmes paramètres que ceux dont sont tirés les chiffres des textes ; pour ces durées, le texte et le comportement ne divergent donc pas.
  • Les résultats des vérifications, captures d’écran comprises, sont supprimés après 13 mois (le plus récent par domaine est conservé), les chiffres des extensions après 13 mois, les journaux de remise des alertes après 90 jours, les demandes d’assistance après 24 mois.
  • Le retrait d’un domaine supprime les données du domaine, y compris les vérifications, formulaires, constats, captures d’écran, rapports, tâches, destinations et journaux d’alerte, incidents, données de livraison, identifiants pour l’analyse derrière la connexion et preuves.
  • La suppression d’un compte a lieu immédiatement ; les espaces de travail sans autres membres sont supprimés avec leurs données, les espaces de travail avec d’autres membres reviennent à un autre membre, d’abord aux administrateurs, et parmi eux au plus ancien. Jusqu’à l’expiration de leurs propres durées subsistent : les journaux dont les entrées conservent l’ancien numéro de compte, qui ne renvoie plus à aucun compte existant, y compris l’entrée de suppression, ainsi que les e-mails envoyés, la preuve de la conclusion du contrat, les demandes d’assistance, les rapports des vérifications de prospects (jusqu’à 90 jours) et les données de facturation chez Stripe ; les détails figurent dans la Politique de confidentialité.
  • Les données supprimées subsistent dans les sauvegardes jusqu’à leur expiration après 14 jours. Aucune suppression ciblée n’a lieu au sein d’une sauvegarde ; si une sauvegarde est restaurée, les demandes de suppression ultérieures connues sont réexécutées manuellement.

9. Organisation et réexamen

  • Personnes : le service est actuellement exploité par le propriétaire lui-même. D’autres personnes ne reçoivent un accès qu’après un engagement de confidentialité et uniquement dans la mesure nécessaire, et ne traitent les données que sur nos instructions (Art. 29 et Art. 32(4) RGPD).
  • Sous-traitants ultérieurs : nous ne faisons appel à eux qu’après examen de leurs garanties et en vertu d’un contrat conforme à l’Art. 28(4) RGPD, et les énumérons sur la page Sous-traitants ultérieurs ; les détails sont régis par le contrat de sous-traitance.
  • Violations de données à caractère personnel : si une violation de données à caractère personnel affecte des données traitées en tant que sous-traitant, nous en informons le Client sans délai injustifié, si possible dans les 48 heures ; les détails sont régis par le contrat de sous-traitance.
  • Signalement des vulnérabilités : nous acceptons les signalements sur Sécurité et via le fichier /.well-known/security.txt.
  • Liste de contrôle de configuration et de lancement : dans l’espace d’administration, une liste de contrôle mesure l’état des paramètres pertinents pour la sécurité, comme la sauvegarde, les administrateurs sans second facteur, la configuration de la messagerie et le signal de vie, et affiche les écarts.
  • Réexamen de ces mesures (Art. 32(1)(d) RGPD) : à chaque modification importante du service, après chaque incident de sécurité et sinon au moins une fois par an. Ce faisant, nous évaluons si les mesures sont efficaces et correspondent toujours aux risques, et consignons le résultat dans une nouvelle version de cette page ou, si rien ne change, avec la date du réexamen à la section 11. En continu, la liste de contrôle de configuration et de lancement mesure l’état des paramètres qu’elle couvre.
  • Audits externes : aucun test d’intrusion externe n’est actuellement commandé, et il n’existe aucune certification de sécurité. Nous le précisons ici afin que personne ne suppose le contraire.

10. Prévu, pas encore mis en œuvre

Ces points ne constituent pas des mesures engagées tant qu’ils ne sont pas listés ici comme mis en œuvre dans une nouvelle version :

  • Sauvegarde sur un second site : une copie chiffrée de la sauvegarde nocturne en dehors du serveur, afin que même une perte totale du serveur n’entraîne pas de perte de données.
  • Second point de contrôle : la confirmation indépendante des vérifications par navigateur depuis un second emplacement est préparée dans le service mais non configurée. Sans elle, il n’y a pas de confirmation depuis un second emplacement.
  • Renforcement de l’administration des serveurs : il se poursuit. Pour les raisons indiquées à la section 1, nous n’en publions pas les détails.

11. État et version

  • Version 1.1 · Dernière mise à jour : 22 octobre 2026 · en cas de divergence entre les versions linguistiques, c’est désormais la version polonaise qui fait foi, et non plus la version allemande ; aucune autre modification.
  • Version 1.0 · Dernière mise à jour : 11 octobre 2026 · première version en tant que page distincte ; auparavant Annexe 2 du contrat de sous-traitance. Corrigé par rapport à l’annexe précédente : le test de restauration a lieu chaque semaine, les sauvegardes se trouvent sur le même serveur, aucune suite de tests automatisés ne s’exécute avant chaque déploiement, les connexions dans le réseau interne ne sont pas chiffrées de bout en bout. Nouvellement décrits : chiffrement des identifiants pour l’analyse derrière la connexion, isolation du scanner, surveillance croisée et alerte d’erreur.
  • Les modifications sont publiées avec un nouveau numéro de version ici et dans la vue d’ensemble Modifications des documents contractuels ; pour tout affaiblissement des mesures, le préavis du contrat de sous-traitance s’applique.
  • En cas de divergence entre les versions linguistiques, la version polonaise fait foi.