# Registre des activités de traitement — ShieldOne *Modèle nLPD (art. 12) — **Version 1.29, en vigueur le 11 octobre 2026*** *(Version 1.28 du 5 octobre 2026 — remplacée le 11 octobre 2026, consultable en archive : `/legal/archive/08-registre-traitements-v1.28.md`.)* *(Version 1.27 du 3 octobre 2026 — remplacée le 5 octobre 2026, consultable en archive : `/legal/archive/08-registre-traitements-v1.27.md`.)* *(Version 1.26 du 2 octobre 2026 — remplacée le 3 octobre 2026, consultable en archive : `/legal/archive/08-registre-traitements-v1.26.md`.)* *(Version 1.25 du 2 octobre 2026 — remplacée le même jour, consultable en archive : `/legal/archive/08-registre-traitements-v1.25.md`.)* *(Version 1.24 du 1er octobre 2026 — remplacée le 2 octobre 2026, consultable en archive : `/legal/archive/08-registre-traitements-v1.24.md`.)* *(Version 1.23 du 1er octobre 2026 — remplacée le même jour, consultable en archive : `/legal/archive/08-registre-traitements-v1.23.md`.)* *(Version 1.22 du 1er octobre 2026 — remplacée le même jour, consultable en archive : `/legal/archive/08-registre-traitements-v1.22.md`.)* *(Version 1.21 du 30 septembre 2026 — remplacée le 1er octobre 2026, consultable en archive : `/legal/archive/08-registre-traitements-v1.21.md`.)* *(Version 1.20 du 29 septembre 2026 — remplacée le 30 septembre 2026, consultable en archive : `/legal/archive/08-registre-traitements-v1.20.md`.)* *(Version 1.19 du 29 septembre 2026 — remplacée le même jour, consultable en archive : `/legal/archive/08-registre-traitements-v1.19.md`.)* *(Version 1.18 du 28 septembre 2026 — remplacée le 29 septembre 2026, consultable en archive : `/legal/archive/08-registre-traitements-v1.18.md`.)* *(Version 1.17 du 28 septembre 2026 — remplacée le même jour, consultable en archive : `/legal/archive/08-registre-traitements-v1.17.md`.)* *(Version 1.16 du 27 septembre 2026 — remplacée le 28 septembre 2026, consultable en archive : `/legal/archive/08-registre-traitements-v1.16.md`.)* *(Version 1.15 du 27 septembre 2026 — remplacée le même jour, consultable en archive : `/legal/archive/08-registre-traitements-v1.15.md`.)* *(Version 1.14 du 27 septembre 2026 — remplacée le même jour, consultable en archive : `/legal/archive/08-registre-traitements-v1.14.md`.)* *(Version 1.13 du 26 septembre 2026 — remplacée le 27 septembre 2026, consultable en archive : `/legal/archive/08-registre-traitements-v1.13.md`.)* *(Version 1.12 du 25 septembre 2026 — remplacée le 26 septembre 2026, consultable en archive : `/legal/archive/08-registre-traitements-v1.12.md`.)* *(Version 1.11 du 19 septembre 2026 — remplacée le 25 septembre 2026, consultable en archive : `/legal/archive/08-registre-traitements-v1.11.md`.)* *(Version 1.10 du 19 septembre 2026 — remplacée le même jour, consultable en archive : `/legal/archive/08-registre-traitements-v1.10.md`.)* *(Version 1.9 du 18 septembre 2026 — remplacée le 19 septembre 2026, consultable en archive : `/legal/archive/08-registre-traitements-v1.9.md`.)* *(Version 1.8 du 18 septembre 2026 — remplacée le même jour, consultable en archive : `/legal/archive/08-registre-traitements-v1.8.md`.)* *(Version 1.7 du 16 septembre 2026 — remplacée le 18 septembre 2026, consultable en archive : `/legal/archive/08-registre-traitements-v1.7.md`.)* *(Version 1.6 du 14 août 2026 — remplacée le 16 septembre 2026, consultable en archive : `/legal/archive/08-registre-traitements-v1.6.md`.)* *(Version 1.5 du 13 août 2026 — remplacée le 14 août 2026, consultable en archive : `/legal/archive/08-registre-traitements-v1.5.md`.)* *(Version 1.4 du 6 août 2026 — remplacée le 13 août 2026, consultable en archive : `/legal/archive/08-registre-traitements-v1.4.md`.)* *(Version 1.3 du 1er août 2026 — remplacée le 6 août 2026, consultable en archive : `/legal/archive/08-registre-traitements-v1.3.md`.)* *(Version 1.2 du même jour — remplacée, consultable en archive : `/legal/archive/08-registre-traitements-v1.2.md`.)* *(Version 1.1 du 19 juillet 2026 — remplacée, consultable en archive : `/legal/archive/08-registre-traitements-v1.1.md`.)* *L'empreinte SHA-256 du présent document figure au manifeste `/legal/EMPREINTES.md`.* *(Version 1.0 du 11 juin 2026 — remplacée.)* **Responsable du traitement / Sous-traitant** : ShieldOne, Sacha Frija, Chemin Frisco 6, 1208 Genève, Suisse — contact@shieldone.ch ShieldOne agit comme **responsable du traitement** pour ses propres traitements administratifs et techniques (relation client, facturation, sécurité de la plateforme) **et pour l'espace personnel**, utilisé sans entreprise cliente (volet personnel). ShieldOne agit comme **sous-traitant** pour les données que les entreprises clientes gèrent au moyen de la plateforme (volet professionnel). **Périmètre de la présente version** : ShieldOne est une plateforme **professionnelle (B2B)**, destinée aux entreprises de sécurité privée et à leurs clients. Elle comporte en outre un **espace personnel**, pour les comptes qui ne sont rattachés à aucune entreprise cliente (traitements R12 et R13). Le Service est accessible par navigateur web ; une application pour téléphone est en préparation. Le service annoncé sur le site « Travel » n'est pas ouvert ; aucun traitement n'est mené à son titre en dehors de la liste d'attente (R11). Les demandes d'organismes de formation reçues par le site relèvent de R9bis jusqu'à leur validation. **ShieldOne Services** (mise en relation d'un particulier avec une société de sécurité validée par ShieldOne) fait l'objet des traitements **R15** (demandes des particuliers) et **R16** (sociétés inscrites). ShieldOne en est **responsable du traitement**. ShieldOne ne perçoit aucune commission sur une mission ; l'accès des sociétés au logiciel professionnel est une licence logicielle par agent. **ShieldOne Local** (fil d'information de sécurité et de vie locale de Suisse romande, sources officielles et publications d'habitants modérées) fait l'objet des traitements **R19** (fil, publications, signalements, masquages, lieux et leur adresse précise) et **R20** (collecte des sources officielles). ShieldOne en est **responsable du traitement** — un particulier n'est pas une organisation ; personne d'autre ne peut porter cette qualité pour ses publications. **ShieldOne Training** (catalogue de formations publiées par des organismes de formation validés par ShieldOne ; le titulaire d'un compte personnel y demande à s'inscrire, l'organisme accepte ou refuse la demande, puis indique si la personne a participé), ouvert le 10 octobre 2026, fait l'objet des traitements **R21** (organismes de formation : validation, compte, suspension, cours publiés) et **R22** (demandes et inscriptions des agents). La demande d'accès d'un organisme reçue par le site relève de **R9bis** jusqu'à sa validation ; une inscription à la liste « prévenez-moi au lancement » reste régie par **R11**. ShieldOne en est **responsable du traitement**. L'organisme de formation qui reçoit le prénom, le nom et l'adresse e-mail d'un agent les traite **sous sa propre responsabilité**, et non pour le compte de ShieldOne (*Conditions de ShieldOne Training*, article 10.3) : il est destinataire de ces données, non sous-traitant. ShieldOne n'encaisse aucun paiement : le prix d'un cours est affiché par l'organisme et réglé directement à celui-ci ; ShieldOne ne prélève rien sur ce prix et ne facture rien en fonction des inscriptions. Aucun paiement en ligne n'est en service dans ShieldOne Training. Le **profil pro** (fiche que le titulaire d'un compte personnel tient pour présenter son parcours d'agent, déclarée ou vérifiée par ShieldOne, montrée société par société) fait l'objet du traitement **R23**, et **ShieldOne Jobs** (offres d'emploi publiées par des sociétés clientes, candidatures des titulaires d'un compte personnel), ouverts le 10 octobre 2026, du traitement **R24**. ShieldOne en est **responsable du traitement** pour ce qu'elle enregistre. La société qui reçoit une candidature la traite **sous sa propre responsabilité** : elle est destinataire de ces données, non sous-traitant de ShieldOne. ShieldOne n'est pas une agence de placement : elle ne propose, ne sélectionne, ne classe et ne recommande aucun candidat. Le **module citoyen est fermé** depuis le 19 juillet 2026 : il est **désactivé et inaccessible**, aucun compte ne peut y accéder, et la vérification conduite le même jour a établi qu'**aucun compte citoyen n'existe** dans la base. Le code correspondant est **conservé en l'état, désactivé** — il n'a pas été supprimé, ce qui est sans effet sur les personnes puisque le module est inatteignable. La **suppression des collections résiduelles est planifiée et n'a pas été exécutée**. Les traitements correspondants figurent en **partie D (Traitements clos)**. Le **module « listes de personnes »** est **en service depuis le 19 juillet 2026**. Il figure en **partie B** sous la référence **S9**. Il s'agit d'un registre neutre : l'entreprise cliente définit ses propres listes, **ShieldOne n'en livre aucune**, et la **photo de visage est désactivée par défaut** au niveau de chaque entreprise. ## A. Traitements pour lesquels ShieldOne est RESPONSABLE | # | Traitement | Personnes concernées | Catégories de données | Finalité | Base légale | Destinataires / sous-traitants | Transfert hors CH | Durée de conservation | |---|---|---|---|---|---|---|---|---| | R1 | Relation client et comptes des entreprises clientes | Représentants des entreprises clientes (propriétaire, personnes de contact) | Raison sociale, nom et prénom du contact, adresse e-mail professionnelle, adresse postale, contenu des échanges | Conclusion et suivi du contrat, support, information sur le service | Exécution du contrat / intérêt légitime | Google Firebase (hébergement) | — (CH, Zurich) | Durée du contrat, puis suppression à la clôture du compte — **aucune purge automatique** —, sous réserve des durées légales de conservation | | **R1bis** | **Engagement d'une entreprise cliente : habilitation du signataire et pièce de preuve** *(ajouté le 28 septembre 2026, avant la mise en service)* | Personne qui accepte, au nom d'une entreprise cliente, les conditions de ShieldOne : à l'**activation de Pro** par la société depuis ShieldOne Services (R16), ou à la **connexion d'un responsable** d'une entreprise déjà cliente, lorsque l'acceptation des *Conditions générales de vente et d'utilisation*, de l'*Annexe de traitement des données* ou la déclaration d'habilitation manque ou ne porte pas sur la version en vigueur | **Déclaration** : nom et fonction déclarés par la personne, case « habilité(e) à engager la société », identifiant du compte ; à la connexion, en outre le nom enregistré sur le compte et son rôle ; **acceptations**, une case par document : version et empreinte de chaque texte accepté, date et heure fixées par le serveur ; à l'activation, en outre le tarif, le nombre d'agents et le montant mensuel acceptés (R16) ; **pièce de preuve PDF** récapitulant ces éléments avec l'identifiant ShieldOne de la société et, à l'activation, sa raison sociale et son numéro IDE (à la connexion, son nom, sans tarif), et son empreinte ; état de production et d'envoi de la pièce ; **vérification du signataire** : case « Signataire vérifié au registre du commerce », cochée par ShieldOne, avec la date et l'identifiant de la personne de ShieldOne qui l'a cochée — tant qu'elle ne l'est pas, une alerte interne porte le nom de la société et le nom et la fonction déclarés ; traces de chaque consultation de la pièce et de chaque vérification | Garder la preuve de l'engagement de la société, de ses termes et de la personne qui l'a pris ; en remettre une copie à la société ; permettre à ShieldOne de vérifier que cette personne est habilitée à engager la société | Exécution du contrat / intérêt légitime (preuve de la conclusion du contrat et de ses termes) | Google Firebase (hébergement) ; **Brevo** (envoi de la pièce par e-mail, en pièce jointe : à l'activation, à l'adresse du compte de la société ; à la connexion, à l'adresse vérifiée du compte de la personne, lue au service d'authentification au moment de l'envoi). À la connexion, un échec passager de la production ou de l'envoi de la pièce est retenté automatiquement pendant 24 heures au plus ; à l'activation, ShieldOne peut les reprendre. La pièce n'est lisible depuis l'application par personne, à l'exception d'un administrateur de ShieldOne, et chaque consultation est **tracée avant que la pièce ne soit rendue** | Pièce : stockage de fichiers de Google Cloud, **région de Zurich (`europe-west6`)** ; autres données : voir la note sur la localisation des services Google ci-dessous ; Brevo : France | **Conservées sans limite, avec le contrat de la société** : ni la fin du contrat, ni la suppression de la société ou d'un compte n'effacent la déclaration, les acceptations, la pièce, la vérification ou les traces ; la pièce n'est jamais réécrite | | R2 | Facturation et comptabilité | Entreprises clientes et leurs représentants | Données de facturation, montants, échéances, justificatifs comptables | Établissement des factures, encaissement, tenue de la comptabilité | Obligation légale (art. 958f CO) / exécution du contrat | Google Firebase ; établissement bancaire | — (CH) | **10 ans** (obligation légale de conservation des pièces comptables) | | R3 | Comptes d'accès à la plateforme (couche technique) | Utilisateurs professionnels (propriétaire, managers, agents, clients du Client) | Identifiant, adresse e-mail, empreinte du mot de passe, jetons de session et d'autorisation, horodatage de connexion. **Depuis le 16 septembre 2026, deux fiches techniques internes sont en outre écrites pour tout compte** : ① une **fiche d'adresse**, qui associe au compte son adresse e-mail — conservée **en clair**, et sous forme d'**empreinte** qui sert de clé ; une seule adresse par compte, celle du service d'authentification ; ② une **fiche des moyens de connexion** : pour chacun (adresse e-mail et, le cas échéant, numéro de téléphone vérifié), une **empreinte calculée sans valeur secrète** — une telle empreinte **permet, par calcul, de retrouver** l'adresse ou le numéro dont elle est tirée. S'y ajoute un **annuaire des appartenances** (rôle, entreprise, attributs d'un manager, compte actif ou désactivé), copie des autorisations du compte : **son écriture est fermée**, et, à la date de la présente version, seules des fiches de la société de démonstration, fictive, y ont été inscrites. Ces fiches ne sont lisibles ni modifiables depuis l'application par personne, administrateur compris | Authentification, contrôle d'accès, cloisonnement multi-locataire | Exécution du contrat / intérêt légitime (sécurité) | Google Firebase Authentication, Google reCAPTCHA (App Check) ; Google Firebase (hébergement des fiches techniques) | **US (reCAPTCHA). Firebase Authentication : [À VÉRIFIER]** — service sans réglage régional, **non couvert par l'hébergement suisse**. Fiches techniques : — (CH, Zurich) | Durée du compte. À la suppression du compte, les fiches techniques et les appartenances sont effacées par une **tâche déclenchée par cette suppression** ; un échec de cette tâche n'est pas signalé à la personne. Journaux d'authentification : **durée fixée par le paramétrage du prestataire (Google Firebase Authentication), non par ShieldOne — à confirmer par relevé de console** | | R3bis | **Vérification du numéro de téléphone des agents par SMS** | Agents | Numéro de téléphone au format international, horodatage de la vérification, données du reCAPTCHA invisible chargé à cette occasion. Le numéro vérifié est associé au compte d'accès | Sécuriser l'accès à l'application : la confirmation du numéro est **obligatoire** pour tout agent, y compris lorsque son compte a été créé par son manager | Exécution du contrat / intérêt légitime (sécurité) | **Firebase Phone Auth (Google)**, Google reCAPTCHA | **US** | Durée du compte | | R3ter | **Acheminement des notifications** | Utilisateurs professionnels ayant accepté les notifications | Jeton d'appareil enregistré sur le compte, contenu de la notification | Alerter l'utilisateur d'un événement le concernant (alerte, demande, validation) | Exécution du contrat / intérêt légitime | **Google Firebase Cloud Messaging** | **[À VÉRIFIER]** — infrastructure de distribution **mondiale**, sans réglage régional, **non couverte par l'hébergement suisse** | Jeton conservé pour la durée du compte ; **aucune purge planifiée des jetons**. Conservation chez le prestataire : **[À VÉRIFIER]** | | R4 | Journaux d'erreurs applicatifs et journaux techniques de sécurité | Tous les utilisateurs ; toute personne utilisant le formulaire « mot de passe oublié », qu'elle ait un compte ou non | Journaux d'erreurs applicatifs, journaux d'accès et d'événements de sécurité, adresse IP, identifiant technique, type de navigateur. Avant envoi à Sentry, les **adresses e-mail et identifiants de compte sont masqués**, et **seulement dans une partie de l'événement** (message, libellé des erreurs, fil des actions précédentes) ; ce masquage **ne couvre ni** les données personnelles figurant en texte libre dans une trace d'erreur, **ni** les chemins techniques des piles d'appel. **Tenus par ShieldOne**, en outre : ① le **journal des événements de sécurité** — type d'événement, verdict, gravité, date et heure, identifiant du compte, rôle, **adresse e-mail**, entreprise, fonction concernée, bref détail technique et, le cas échéant, mesure chiffrée — et les **alertes** qui en dérivent lorsqu'une règle de détection se déclenche (règle, gravité, identifiant du compte, rôle, **adresse e-mail**, entreprise, fonction concernée, nombre et seuil mesurés, date) ; ② des **compteurs par compte** (nombre d'appels à certaines fonctions par minute, volume de données lu par heure) ; ③ le **compteur anti-abus du formulaire « mot de passe oublié »** : empreinte calculée à partir de l'adresse IP transmise, **sans valeur secrète** et tronquée — elle **permet, par calcul, de retrouver l'adresse IP** —, heure et nombre de demandes ; il n'est rattaché à aucun compte | Sécurité, diagnostic, prévention et détection des abus | Intérêt légitime / obligation légale | **Sentry (région UE, Allemagne), Google.** Le journal ①, ses alertes et les compteurs ② et ③ sont tenus par **ShieldOne** (hébergement Google Firebase) ; le journal ① et ses alertes ne sont lisibles que de l'**administration de ShieldOne** | **UE (Sentry, Allemagne). Journaux Google Cloud : [À VÉRIFIER].** ①, ② et ③ : — (CH, Zurich) | Journaux d'erreurs chez Sentry : **durée fixée par le paramétrage du prestataire, non par un mécanisme ShieldOne — à confirmer par relevé de console.** Journaux Google Cloud : **30 jours** pour les journaux de requêtes et d'exécution, réglage de la plateforme relevé le 26 septembre 2026 (les journaux d'audit des opérations d'administration de la plateforme sont gardés **400 jours**, réglage de la plateforme relevé le 26 septembre 2026). ① **Aucune durée n'est appliquée**, ni aux entrées ni aux alertes qui en dérivent : elles sont conservées sans limite, **y compris après la suppression du compte**. ② Supprimés par une tâche planifiée quotidienne une fois passées **24 heures**, par lots (un reste est repris la nuit suivante). ③ **Aucune durée n'est appliquée** ; n'étant rattaché à aucun compte, il n'est pas effacé par la suppression d'un compte | | R4bis | **Envoi des e-mails transactionnels** *(ajouté le 01.08.2026 — traitement en service, jusque-là absent du registre)* | Destinataires des e-mails du Service : personnes invitées à créer un compte, titulaires d'un compte demandant la réinitialisation de leur mot de passe ou la vérification de leur adresse e-mail, ou avisés d'une alerte de sécurité les concernant, clients des entreprises clientes recevant un devis ou une facture, prospects dont la demande de démonstration est transmise à ShieldOne par e-mail | Adresse e-mail et nom du destinataire, objet et corps du message, pièces jointes le cas échéant (PDF de devis et de factures ; depuis le 28 septembre 2026, pièce de preuve de l'engagement d'une entreprise cliente — voir R1bis). Adresse de réponse configurée par l'entreprise cliente. Pour la réinitialisation du mot de passe et la vérification professionnelle : le lien d'action contenu dans le message ; pour l'inscription personnelle par e-mail : le code à six chiffres | Acheminer les e-mails du Service : invitations de comptes, **réinitialisation du mot de passe**, **vérification de l'adresse e-mail**, envoi de devis et de factures, envoi de la pièce de preuve de l'engagement d'une entreprise cliente (R1bis), demandes de démonstration, avis d'alerte de sécurité adressés à l'administration de ShieldOne et, en cas d'échecs répétés de saisie du code de vérification demandé à la connexion, au titulaire du compte concerné. Le résumé quotidien adressé aux clients des entreprises clientes n'en envoie aucun à ce jour | Exécution du contrat / intérêt légitime | **Brevo** (envoi) ; Google Firebase (déclenchement) | **UE (France)** — protection adéquate au titre de l'annexe 1 OPDo | Conservation chez ShieldOne : trace d'envoi rattachée au document concerné, pour la durée du contrat ; pour les e-mails adressés par ShieldOne aux utilisateurs (invitations, réinitialisation, vérification, alertes de sécurité), la trace relève de R10 ②. Conservation chez le prestataire : **durée fixée par le paramétrage de Brevo, non par ShieldOne** | | R5 | Statistiques d'usage anonymisées | — (aucune personne identifiable après anonymisation) | Volumes d'usage agrégés, indicateurs de performance et de fiabilité, sans donnée identifiante ni possibilité de réidentification. **Depuis le 16 septembre 2026**, s'y ajoute le **comptage, par jour, des affichages de la page d'accueil du site et des clics sur ses quatre rubriques** ; depuis le 19 septembre 2026, un **total journalier des clics sur les boutons « Créer un compte » et « Créer un compte gratuit »** s’y ajoute. Ce total ne mesure ni des visiteurs uniques ni des comptes créés : aucun cookie, aucun identifiant, aucune adresse IP enregistrée ; contre les abus, une empreinte salée de l'adresse IP est gardée en mémoire du serveur tant que celui-ci fonctionne (quelques heures), jamais écrite | Amélioration du service, dimensionnement de l'infrastructure | Intérêt légitime | Google Firebase | — (CH) | Sans limite (données anonymisées, hors champ de la nLPD une fois l'anonymisation effective) | | R6 | **Journal des acceptations — écran de première connexion** | Utilisateurs professionnels | Identifiant de l'utilisateur, son rôle et son entreprise, date et heure de l'acceptation (horloge serveur), **version ET empreinte SHA-256** des documents concernés : conditions d'utilisation acceptées, politique de confidentialité dont l'utilisateur déclare avoir pris connaissance et, pour un agent, charte d'information des collaborateurs dont il atteste la lecture. Deux enregistrements : l'**état courant**, porté par le compte, et un **historique append-only** conservant chaque acceptation successive | Preuve de l'acceptation des documents contractuels, traçabilité du consentement | Obligation légale (preuve) / exécution du contrat | Google Firebase | — (CH) | État courant : supprimé avec le profil du compte. Historique : **aucune durée n'est appliquée** ; il n'est pas effacé par la suppression du compte (voir la note relative à R6) | | R7 | **Chargement des bibliothèques techniques depuis un domaine Google** | Tous les visiteurs de l'application | Adresse IP, données techniques du navigateur | Chargement du kit de développement Firebase (`www.gstatic.com`) et des ressources reCAPTCHA au démarrage de l'application | Intérêt légitime (fonctionnement technique du Service) | **Google LLC** | **US** | Durée fixée par Google, non par ShieldOne | | R7bis | **Chargement des polices de caractères depuis un domaine Google** | Tous les visiteurs de l'application | Adresse IP, données techniques du navigateur. Le déclenchement d'un téléchargement de police de secours **révèle indirectement la nature des caractères affichés** (alphabets non latins, émojis) | Rendu des textes de l'interface : police principale, et **polices de secours appelées à la demande** par le moteur de rendu graphique lorsqu'un caractère est absent des polices déjà chargées (`fonts.gstatic.com`) | Intérêt légitime (fonctionnement technique du Service) | **Google LLC** | **US** | Durée fixée par Google, non par ShieldOne | | R7ter | **Ouverture d'un lieu dans Google Maps** | Utilisateur activant le bouton, destinataire d'un message de position | Coordonnées du lieu, adresse IP | Permettre l'itinéraire vers un lieu affiché par le Service ; lien de position inséré dans le message d'alerte. **Transmission uniquement sur action explicite** ; aucun appel n'est fait sans elle | Intérêt légitime / exécution du contrat | **Google LLC** | **US** | Durée fixée par Google, non par ShieldOne | | R7quater | **Service des pages du site et de l'application** | Tous les visiteurs du site et de l'application | Adresse IP, données techniques du navigateur | Servir les pages du site et les fichiers de l'application | Intérêt légitime (fonctionnement technique du Service) | **Google Firebase Hosting** | Réseau de diffusion du prestataire, **sans réglage régional : localisation non établie** — **non couvert par l'hébergement suisse** | Durée fixée par Google, non par ShieldOne | | **R8** | **Données de prospect — inscription spontanée sans relation contractuelle** | Représentants d'entreprises s'étant inscrites spontanément au Service, sans qu'aucun contrat n'ait été conclu | Prénom, nom, adresse e-mail professionnelle, numéro de téléphone, raison sociale | Démarche précontractuelle : conservation de la demande d'inscription et **recontact au lancement** du Service | **Démarche précontractuelle / intérêt légitime** | Google Firebase (hébergement, authentification) | Voir la note sur la localisation des services Google ci-dessous | **Aucune durée n'est appliquée.** Aucune purge, automatique ou planifiée, n'existe pour ce traitement. Le sort du compte — recontact au lancement ou suppression — **relève d'une décision qui n'est pas prise à la date de la présente version** | | **R9** | **Pipeline commercial — démarchage sortant** *(ajouté le 13 août 2026 ; le traitement était en service depuis le 12 août 2026 et absent du registre — l'écart est énoncé ici plutôt que passé sous silence)* | Dirigeants et personnes de contact d'entreprises de sécurité privée **démarchées par ShieldOne**, avec lesquelles aucune relation contractuelle n'existe | Raison sociale, nom et fonction du contact, adresse e-mail professionnelle, numéro de téléphone, canton, effectif estimé, provenance du contact, état de la démarche, motif de refus le cas échéant, et **comptes rendus d'échanges horodatés rédigés par ShieldOne** | Prospection commerciale : suivre les démarches engagées, **conserver la raison de ne pas recontacter une personne qui l'a refusé**, mesurer la conversion | **Intérêt légitime** (démarchage entre entreprises) | Google Firebase (hébergement) | — (CH, Zurich) | **Aucune durée n'est appliquée et aucune purge n'existe.** Décision du 13 août 2026, motivée à la note R9 ci-dessous | | **R9bis** | **Demandes de démonstration, d'espace professionnel et d'organisme de formation reçues par le site** *(complété le 29 septembre 2026 : les demandes d'espace professionnel de la page `/entreprise` étaient reçues depuis le 28 septembre 2026 sans y être nommées — l'écart est énoncé ici plutôt que passé sous silence)* | Personnes demandant une démonstration depuis le site ; représentants d'une entreprise de sécurité demandant l'ouverture d'un espace professionnel (page `/entreprise`) ; représentants d'un organisme de formation demandant à être recontactés (page `/organismes-formation`) | Nom, raison sociale, coordonnée de contact (adresse e-mail ou numéro de téléphone), date de la demande (horloge serveur), état de traitement, résultat de l'avis adressé à ShieldOne. Pour une demande d'espace professionnel ou d'organisme de formation : raison sociale ou nom de l'organisme, canton, adresse e-mail de contact et provenance de la demande ; une demande d'espace professionnel fait en outre naître la fiche de la société à valider (Services) ; une demande d'organisme de formation validée par ShieldOne porte en outre l'identifiant de l'organisme ainsi créé (R21). Compteur anti-abus du formulaire : empreinte calculée à partir de l'adresse IP transmise, **sans valeur secrète** et tronquée — elle **permet, par calcul, de retrouver l'adresse IP** —, heure et nombre de demandes ; il n'est rattaché à aucune personne | Répondre à la demande ; pour une demande de démonstration ou d'espace professionnel, le cas échéant l'inscrire au pipeline commercial (R9) — une demande d'organisme de formation ne s'y convertit jamais : ShieldOne l'examine et peut la valider, ce qui fait naître la fiche de l'organisme et son compte d'accès (R21) ; limiter les abus du formulaire | Démarche précontractuelle / intérêt légitime | Google Firebase (hébergement) ; **Brevo** (avis adressé à ShieldOne) | — (CH, Zurich) pour la conservation ; **UE (France)** pour l'avis | **Aucune durée n'est appliquée**, ni à la demande ni au compteur anti-abus ; aucune purge n'existe. Une demande reprise au pipeline commercial relève en outre de R9 ; la fiche et le compte d'un organisme de formation validé relèvent de R21 | | **R10** | **Journaux techniques à durée bornée** *(ajouté le 13 août 2026)* | Utilisateurs professionnels ; destinataires des e-mails envoyés par ShieldOne | Trois journaux distincts. ① **Historique de connexion** : date et heure serveur, adresse IP, étiquette d'appareil (famille de navigateur, version majeure, système), empreinte de ce type d'appareil et indication « appareil jamais vu », identifiant du compte, adresse e-mail, rôle et entreprise — **l'agent utilisateur brut n'est pas conservé**. ② **Journal des e-mails émis par ShieldOne** : nature du flux, adresse du destinataire, objet, résultat de l'envoi. ③ **Journal des erreurs applicatives remontées** : titre, message, localisation technique, nombre d'occurrences — **ni pile d'appel, ni contexte utilisateur** | ① permettre au titulaire du compte de repérer une connexion qu'il n'a pas faite ; ② répondre à une contestation de réception et conserver la trace d'un envoi ; ③ constater et corriger les défauts du Service | Intérêt légitime (sécurité et fiabilité du Service) | Google Firebase (hébergement) ; Sentry pour l'origine du journal ③ | — (CH, Zurich) pour la conservation ; **UE (Allemagne)** pour Sentry | **180 jours**, appliqués par des tâches planifiées quotidiennes. L'historique de connexion est **en outre supprimé avec le compte** | | **R11** | **Liste « prévenez-moi au lancement »** *(ajouté le 16 septembre 2026, le jour de la mise en service)* | Visiteurs du site demandant à être prévenus de l'ouverture d'un service en préparation | **Adresse e-mail**, **service choisi** (liste fermée) et **date d'inscription** (horloge serveur). **Rien d'autre** : ni nom, ni adresse IP, ni information sur le navigateur. Aucun compte n'est créé | Informer **une seule fois** de l'ouverture du service choisi. *(Ajouté le 29 septembre 2026.)* **Compter**, chaque nuit, le **nombre d'inscriptions par service et par jour** : seuls le service et la date d'inscription sont lus, jamais l'adresse ; le résultat est un nombre, rangé avec les statistiques de la mesure d'utilisation (R17), sans aucun identifiant, et conservé comme elles sans durée appliquée | **Consentement** (inscription volontaire) ; pour le compte, statistique ne se rapportant à aucune personne | Google Firebase (hébergement) ; **Brevo** pour l'envoi de l'avis, lorsqu'il aura lieu | — (CH, Zurich) pour la conservation ; **UE (France)** pour l'envoi de l'avis. **Aucun envoi n'a lieu tant que le service n'est pas ouvert**, et **aucun e-mail de confirmation** n'est envoyé à l'inscription | Suppression par une tâche planifiée quotidienne une fois passés 729 jours après l'inscription, soit **au plus tard 24 mois** lorsque le lot de la nuit n'est pas plein ; un reste est repris la nuit suivante. **Aucun avis n'a été envoyé et aucun outil d'envoi n'existe à ce jour** : seule cette suppression s'exécute. Le formulaire annonce en outre la suppression de l'inscription à l'envoi de l'avis ; aucun mécanisme ne l'exécute à ce jour. | | **R12** | **Compte personnel : identité, authentification et gestion du compte** | Particuliers titulaires d'un compte qui n'est rattaché à aucune entreprise cliente. Inscription personnelle par e-mail et mot de passe ouverte | Adresse e-mail, qui sert d'identifiant, et état de sa vérification ; nom affiché, s'il est renseigné ; empreinte du mot de passe, tenue par le service d'authentification et non par la base de données de ShieldOne ; jetons de session ; dates de création du compte et de dernière connexion. Vérification par code : empreinte salée du code liée au compte et à une empreinte de l’adresse, dates, état et compteurs des envois et tentatives ; aucun code en clair en base. Deux fiches techniques internes : l'une associe au compte son adresse e-mail (conservée en clair, et sous forme d'empreinte qui sert de clé) ; l'autre, ses moyens de connexion, sous forme d'empreinte calculée **sans valeur secrète** — une telle empreinte **permet, par calcul, de retrouver** l'adresse ou le numéro dont elle est tirée. Le cas échéant, l'état de la validation en deux étapes et son secret, si elle a été activée sur le compte. **Preuve d'acceptation** : version et empreinte des conditions d'utilisation de l'espace personnel (qui comprennent, depuis leur version 1.4, les conditions de ShieldOne Local, article 17) et, avec la mention qu'elle a été présentée et non acceptée, de la politique de confidentialité de l'espace personnel présentée à ce moment ; déclaration d'avoir atteint l'âge minimum et âge auquel elle se rapporte, date et heure fixées par le serveur. **Rien d'autre** : aucune position, aucun jeton de notification, aucune donnée de carte | Tenir le compte et permettre à la personne de s'y connecter ; lui envoyer, à sa demande, l'e-mail de vérification de son adresse et l'e-mail de réinitialisation de son mot de passe ; lui permettre d'obtenir ses données et de supprimer son compte ; conserver la preuve de son acceptation des conditions d'utilisation et de sa déclaration d'âge | Exécution du contrat (conditions d'utilisation de l'espace personnel) / intérêt légitime (sécurité du compte ; preuve de l'acceptation des conditions) | Google Firebase (authentification, base de données, fonctions serveur) ; **Brevo** (envoi du code de vérification ; réinitialisation du mot de passe avec repli Firebase si Brevo n'est pas disponible). **Aucune entreprise cliente, pour un compte qui n'a jamais été rattaché à une entreprise.** Au sein de ShieldOne, l'administration du Service peut y accéder techniquement pour l'exploiter et le dépanner | Données principales en Suisse (région de Zurich) : base de données et fonctions serveur. **Authentification (Google Firebase Authentication)** : service sans réglage régional, localisation non établie ; ces données peuvent être traitées hors de Suisse, y compris aux États-Unis. **Brevo : UE (France)** — protection adéquate au titre de l'annexe 1 OPDo. Garanties de l'art. 16 al. 2 LPD pour un transfert vers un État sans protection adéquate : voir « Points en suspens » | **Durée du compte.** Le challenge de vérification expire après dix minutes, avec cinq tentatives ; les métadonnées sont remplacées au prochain envoi et leur effacement est tenté à la suppression du compte, sans purge périodique à ce jour. Aucune suppression des comptes inactifs n'est appliquée. Preuve d'acceptation : l'état courant, porté par le compte, est supprimé avec le profil ; l'historique, tenu à part (une entrée par acceptation d'une version nouvelle, ni lisible ni modifiable depuis l'application), n'a **aucune durée appliquée** et n'est pas effacé par la suppression du compte, parce qu'il constitue la preuve de l'acceptation. À la suppression du compte par la personne : le compte d'accès et le profil sont supprimés ; l'historique de connexion, les fiches techniques internes et, le cas échéant, le secret de validation en deux étapes sont effacés par une tâche déclenchée par cette suppression, **dont l'échec n'est pas signalé à la personne**. **Subsistent après la suppression** : l'historique des acceptations ; le journal des événements de sécurité et les alertes qui en dérivent (R4 ①, aucune durée n'est appliquée) ; l'empreinte d'adresse IP du formulaire « mot de passe oublié », qui n'est pas rattachée au compte (R4 ③, aucune durée n'est appliquée) ; la trace des e-mails envoyés (R10 ②, 180 jours) ; les rapports d'erreurs déjà transmis à Sentry (R4) ; les e-mails remis à Brevo et les données d'authentification chez Google (durée fixée par ces prestataires) ; les journaux techniques de Google (durée fixée par Google) ; les copies de sauvegarde de la base de données, jusqu'à 98 jours après leur création | | **R13** | **Sécurité du compte personnel** | Titulaires d'un compte personnel ; toute personne qui utilise le formulaire « mot de passe oublié », qu'elle ait un compte ou non | ① **Historique de connexion** : date et heure (horloge serveur), adresse IP, description de l'appareil (famille de navigateur, version principale, système), empreinte de ce type d'appareil, indication « appareil jamais vu », identifiant du compte et adresse e-mail ; l'entrée est écrite par l'application après une connexion réussie, et une connexion menée hors de l'application n'y figure pas. ② **Journal des événements de sécurité** et **alertes** qui en dérivent, ③ **compteurs par compte** et ④ **compteur anti-abus du formulaire « mot de passe oublié »** : les mêmes que pour tout compte, décrits à **R4** (①, ② et ③). ⑤ **Contrôle d'intégrité** : adresse IP et données techniques du navigateur (reCAPTCHA v3) | Permettre à la personne de repérer une connexion qu'elle n'a pas faite et de fermer ses sessions ; détecter et limiter les abus contre le compte et contre le Service | Intérêt légitime (sécurité du compte et du Service) | Google Firebase (hébergement) ; **Google** (reCAPTCHA). L'historique ① n'est rendu **qu'à son titulaire**. Le journal ② et les alertes qui en dérivent ne sont lisibles **que de l'administration de ShieldOne** (R4). Aucune entreprise cliente, pour un compte qui n'a jamais été rattaché à une entreprise. Aucun e-mail n'est envoyé à la personne lors d'une connexion depuis un appareil jamais vu | Conservation : données principales en Suisse (région de Zurich). **États-Unis** : reCAPTCHA (Google). Garanties de l'art. 16 al. 2 LPD : voir « Points en suspens » | ① **180 jours**, appliqués par une tâche planifiée quotidienne, par lots (un reste est repris la nuit suivante) ; l'historique est en outre effacé avec le compte. ②, ③ et ④ : voir R4. ⑤ Durée fixée par ce prestataire, non par ShieldOne | | **R15** | **ShieldOne Services — demandes des particuliers et mise en relation** *(ajouté le 25 septembre 2026, avant l'ouverture du service ; demande sans compte, formulaire structuré, réponses avec prix, avis de refus à tout client et rappel à 48 heures ajoutés le 26 septembre 2026 ; documents joints, types de mission multiples et choix de la localité ajoutés le 27 septembre 2026 ; suppression des documents non transmis à la publication et des documents d'une demande conclue 12 mois après la conclusion ajoutée le même jour ; annonce par e-mail des demandes publiées aux sociétés ajoutée le 3 octobre 2026)* | Titulaires d'un compte personnel qui demandent un service de sécurité ; personnes qui déposent une demande **sans compte**, depuis le site ou l'application | Identifiant du compte ; objet à protéger (site, événement, personne, bien mobile), type de durée, nombre d'agents, **canton et commune**, choisis dans la liste publique des localités de swisstopo, téléchargée et servie par ShieldOne (ni adresse précise, ni position : le bouton « Utiliser ma position » calcule la localité la plus proche dans l'appareil, et la position n'est pas transmise), **code postal** facultatif, dates de début et de fin ; champs structurés facultatifs : un ou plusieurs **types de mission** (le premier, dans l'ordre fixé par ShieldOne, détermine alors la catégorie), **horaires**, mission **armée** ou non, **tenue**, **langues**, **chien**, **véhicule**, **qualifications** requises — une demande qui ne les renseigne pas prend leur valeur neutre (non armée, aucune exigence) ; description libre facultative filtrée (un numéro de téléphone, une adresse e-mail, un site, un réseau social ou une adresse précise y est refusé lorsqu'il est détecté) ; **documents joints facultatifs** (au plus trois, PDF ou image, 10 Mo chacun au plus : le fichier et une fiche qui porte son nom, son type, sa taille, son état et la décision de transmission, avec sa date et l'identifiant de la personne de ShieldOne qui l'a prise) — le serveur vérifie la taille réelle et les premiers octets du fichier reçu et supprime tout fichier non conforme ; pour une image JPEG, PNG ou WebP, le serveur ne garde que ce qui sert à afficher l'image (et, pour une photo JPEG, son sens d'affichage) et retire tout le reste — Exif, dont la position de prise de vue, XMP, IPTC, commentaires, textes et toute autre donnée jointe —, puis réécrit le fichier et supprime l'original, avant toute transmission ; une image dont la structure ne se lit pas jusqu'au bout est supprimée ; les métadonnées d'un PDF ne sont pas retirées, ce que la fiche signale à ShieldOne ; traces de chaque délivrance d'un lien de lecture d'un document (un même lien reste valable 5 minutes et peut être réutilisé pendant ce délai ; par ShieldOne : identifiant du Super Admin ; par une société : identifiants de la société et du compte) et de chaque décision de transmission ; compteur journalier des demandes envoyées, lié au compte ; catégorie déduite ; consentement (version du texte, date et heure serveur) ; état de la demande, motif d'un refus, dates ; réponses des sociétés (canton de la société, délai, nombre d'agents, message, état et, depuis le 26 septembre 2026, **prix** — tarif horaire ou forfait, montant —, conditions, durée de validité de l'offre, langues, qualifications, chien et véhicule proposés) ; pour l'avis de refus et le rappel à 48 heures d'un client qui a un compte, son adresse e-mail est lue au service d'authentification au moment de l'envoi, sans être copiée dans la demande ; marqueurs d'envoi de ces avis (date, issue). **À la conclusion seulement** : prénom, nom et adresse e-mail du client, transmis par e-mail à la société ; le téléphone du client n'est pas collecté ; **demande sans compte** : adresse e-mail (seule coordonnée demandée), empreinte de l'adresse, dates de dépôt et de confirmation, empreintes des liens envoyés (confirmation, rattachement) ; une seule case : déclaration d'avoir au moins 16 ans et acceptation des conditions de Services (article 15 des conditions de l'espace personnel ; version et empreinte du texte, date et heure serveur) ; fiche technique par adresse (empreinte de l'adresse, date de dernière utilisation) ; compteur anti-abus par connexion : empreinte calculée à partir de l'adresse IP transmise (d'une adresse IPv6, de son préfixe /64), **sans valeur secrète** et tronquée — elle **permet, par calcul, de retrouver l'adresse IP** (ou son préfixe) —, heure et nombre de dépôts ; compteur horaire global des dépôts, sans donnée personnelle ; **annonce par e-mail aux sociétés** (depuis le 3 octobre 2026), construite par liste fermée : le ou les types de mission (à défaut, l'objet à protéger), la commune et le canton, les jours de début et de fin (sans les heures), le nombre d'agents et un lien vers la demande qui porte son identifiant — ni identité, ni coordonnée, ni identifiant de compte du client, ni code postal, ni horaires, ni exigences, ni description, ni document ; avec la demande, un **bilan des annonces** : des nombres (sociétés concernées, annonces immédiates, regroupées ou reportées au récapitulatif, envoyées, en échec, remises), sa date et l'état du volume d'envoi de ShieldOne, sans identifiant ni adresse de société ; par société, une **file d'envoi** : identifiants des demandes déjà traitées (les 300 derniers), identifiants en attente de regroupement ou du récapitulatif quotidien (200 au plus chacun) avec leur date de mise en file et le nombre d'essais, compteur des annonces de l'heure, nombre d'annonces qu'une file pleine n'a pas pu garder | Mettre le particulier en relation avec une société de sécurité validée : examen de la demande par ShieldOne, publication anonyme aux sociétés validées — une mission armée seulement aux sociétés dont ShieldOne a enregistré l'autorisation de port d'armes du canton (R16) —, réponses anonymes, transmission des coordonnées à la conclusion ; examen des documents joints par ShieldOne, qui décide **document par document** s'ils sont transmis aux sociétés (un document peut contenir un nom, une enseigne ou un numéro de téléphone, y compris d'un tiers), délivrance des liens de lecture tracée ; pour une demande sans compte : confirmation par un lien envoyé par e-mail (la demande n'est transmise qu'après), avis « propositions reçues » à la première réponse, renvoyé s'il n'a pas pu partir (cinq envois au plus, ou par l'administration), rattachement à un compte par un lien à usage unique valable trente jours (jamais par l'adresse) ; avis au client du refus de sa demande, avec ou sans compte (motif s'il est indiqué, sans lien) ; **un seul rappel, 48 heures après la publication**, si au moins une société a répondu et qu'aucune offre n'est retenue (nombre de réponses, sans nom de société ni prix ; pour une demande sans compte non rattachée, un nouveau lien de rattachement qui remplace le précédent) ; limiter les abus du formulaire (champ piège, limites par connexion, par adresse et pour l'ensemble du service) ; **annoncer par e-mail** chaque demande publiée aux sociétés qui la voient dans l'application, selon leur réglage (R16), avec un plafond de dix annonces par heure et par société au-delà duquel elles sont regroupées, et un passage au récapitulatif quotidien lorsque le quota d'envoi de Brevo est consommé à plus de 80 % ou n'est pas mesurable (voir la note relative à R15 et R16) | Exécution du contrat (conditions de l'espace personnel, art. 15) ; **consentement** pour le partage anonyme de la demande, donné à l'envoi ; demande sans compte : démarche précontractuelle et **consentement** pour le partage anonyme ; limitation des abus : intérêt légitime ; annonce par e-mail de la demande publiée : le même **consentement** au partage anonyme | Google Firebase (hébergement) ; **Brevo** (e-mails aux sociétés et au client, dont la confirmation, l'avis des propositions, l'avis de refus, le rappel à 48 heures et l'annonce des demandes publiées aux sociétés) ; **sociétés de sécurité validées par ShieldOne** (contenu anonyme de la demande publiée et, pour les seuls documents dont ShieldOne a décidé la transmission, ces documents, sous un nom générique — toutes les sociétés à qui la demande publiée est montrée, ainsi que celles qui y ont répondu ; coordonnées du client à la conclusion, pour la seule société concernée, qui les traite ensuite sous sa propre responsabilité ; par e-mail, l'annonce de la demande publiée, limitée à la liste fermée ci-dessus, que la société conserve ensuite **hors du contrôle de ShieldOne**). **En interne** : la fiche complète d'une demande (identité et coordonnées du client, réponses de toutes les sociétés avec leur prix, offre retenue, conclusion) n'est consultable que par un **Super Admin de ShieldOne**, après une nouvelle confirmation de son identité propre à cette demande, et l'accès est **tracé avant que rien ne soit rendu** ; il en va de même de chaque document joint, que seul un Super Admin ouvre, dans les mêmes conditions | Voir la note sur la localisation des services Google ci-dessous ; documents joints : stockage de fichiers de Google Cloud, **région de Zurich (`europe-west6`)**, emplacement relevé de nouveau le 27 septembre 2026 ; Brevo : France | **Demandes non conclues** (refusées, annulées, expirées) et leurs réponses : **supprimées 12 mois après la clôture** par une tâche automatique quotidienne, **active à compter de l'ouverture du service**. **Demandes conclues** : **aucune suppression automatique à ce jour** ; la durée reste à fixer au regard des obligations légales. À la suppression du compte, les demandes en cours sont closes (annulées) et suivent la règle ci-dessus. Compteur journalier : **aucune durée à ce jour**, non effacé à la suppression du compte. **Demande sans compte non confirmée** (avec l'adresse e-mail) : **supprimée 7 jours après le dépôt** par une tâche automatique horaire ; la trace d'un dépôt confirmé (empreinte de l'adresse, dates) aussi. Demande confirmée : règles ci-dessus ; l'adresse e-mail et son empreinte en sont retirées au rattachement à un compte. Compteur anti-abus par connexion : **supprimé 48 heures après l'heure comptée** par la même tâche horaire ; fiche technique par adresse : **supprimée 7 jours après sa dernière utilisation**. **Documents joints** et leur fiche : ils suivent la demande — supprimés avec elle 12 mois après la clôture d'une demande non conclue, ou 7 jours après le dépôt d'une demande sans compte non confirmée ; pour une demande conclue, **supprimés 12 mois après la conclusion** par la tâche automatique quotidienne, la demande restant conservée ; plus tôt, **pour toute demande publiée, conclue ou non**, les documents que ShieldOne n'a pas transmis, **dès la publication** (à défaut, par la même tâche), et un document retiré après la publication, par la même tâche, qui s'exécute chaque nuit ; fichier non conforme : supprimé dès la vérification, sa fiche par une tâche automatique horaire une fois passée une heure ; fichier annoncé mais non reçu ou non vérifié : même tâche ; fichier joint à un dépôt sans compte non accepté : supprimé par une tâche automatique horaire, qui le garde au moins une heure, **sans délai maximal garanti** ; document supprimé, et original d'une image remplacé par sa version sans métadonnées : supprimés de l'espace de stockage, ils passent en **corbeille technique 90 jours** (restaurables par les seuls administrateurs techniques de ShieldOne, jamais par l'application), puis disparaissent ; la fiche suit les sauvegardes de la base (98 jours) ; traces de délivrance des liens de lecture et de transmission : **aucune durée à ce jour** ; **annonce par e-mail** : chez la société destinataire, hors du contrôle de ShieldOne, aucune durée ne peut être fixée ; chez Brevo, durée fixée par le prestataire ; trace d'envoi : 180 jours (R10 ②) ; bilan des annonces : il suit la demande ; file d'envoi d'une société : **aucune durée à ce jour**, bornée en nombre (300 identifiants traités, 200 en attente de regroupement, 200 en attente du récapitulatif) ; elle est effacée avec la fiche de la société, ce que le Service ne permet aujourd'hui que pour une société jamais validée, qui n'a pas de file : en pratique, **aucune file n'est effacée** ; un identifiant peut y rester après la suppression de la demande | | **R16** | **ShieldOne Services — sociétés de sécurité inscrites** *(ajouté le 25 septembre 2026, avant l'ouverture du service ; autorisation de port d'armes, réponses avec prix, acceptation des conditions, activation de Pro par la société et facturation mensuelle ajoutées le 26 septembre 2026 ; déclaration du signataire et pièce de preuve de l'activation ajoutées le 28 septembre 2026, voir R1bis ; réglage des e-mails de nouvelles demandes ajouté le 3 octobre 2026)* | Représentants et personnes de contact des sociétés de sécurité qui s'inscrivent à ShieldOne Services | À l'inscription : nom de la société, nom de la personne de contact, adresse e-mail, numéro de téléphone. Complétés par ShieldOne lors de l'appel de validation : raison sociale, adresse, contact, responsable (prénom, nom, e-mail, téléphone), numéro IDE, autorisation cantonale (canton, numéro, échéance), formule et prix convenus, **tarif par agent** fixé par ShieldOne ; compte d'accès de la société ; **autorisation de port d'armes** : cantons pour lesquels ShieldOne enregistre que la société peut répondre à une mission armée, avec la date et l'identifiant de la personne de ShieldOne qui l'a mise à jour (sans cette mention, aucune demande armée n'est montrée) ; **acceptation des Conditions de Services pour les entreprises** : version et empreinte du texte, date et heure fixées par le serveur, moment de l'acceptation et, à l'activation, nombre d'agents, tarif par agent et montant mensuel acceptés ; **activation de Pro par la société**, depuis le site web seulement : nombre d'agents choisi (plafond), tarif, montant ; nom et fonction de la personne qui accepte, sa déclaration d'habilitation et la pièce de preuve de l'activation : voir **R1bis** ; **relevé quotidien** (23 h 50, heure de Genève) du nombre d'agents actifs dans Pro et des options actives, sans identité d'agent ; **facture mensuelle** (assiette, tarif du contrat, lignes, total), préparée en brouillon le 1er du mois et validée par un Super Admin de ShieldOne avant émission ; réponses envoyées aux demandes, avec prix, conditions et durée de validité ; trace de chaque délivrance d'un lien de lecture d'un document joint transmis (identifiants de la société et du compte, demande, document, date ; un même lien reste valable 5 minutes et peut être réutilisé pendant ce délai) ; **réglage des e-mails de nouvelles demandes** (depuis le 3 octobre 2026) : mode (à chaque demande, par défaut ; un récapitulatif quotidien à 7 h ; aucun e-mail), cantons retenus (tous, par défaut ; ils ne filtrent que l'e-mail), langue (à défaut, celle du canton de l'autorisation), date de la dernière modification et **identifiant du compte qui l'a faite** ; trace de chaque modification au journal de l'administration de ShieldOne (réglage avant et après, identifiants de la société et du compte, date) ; ces e-mails partent à l'adresse du responsable enregistrée par ShieldOne, à défaut à celle de l'inscription, à défaut à celle du contact — une adresse qui peut être nominative | Valider les sociétés admises à répondre, leur permettre de répondre anonymement, transmettre leurs coordonnées au client à la conclusion, préparer le passage au logiciel professionnel ; permettre à la société d'activer elle-même la licence Pro et établir sa facture mensuelle ; prévenir la société par e-mail des nouvelles demandes publiées qu'elle voit, selon son réglage (voir la note relative à R15 et R16) | Démarche précontractuelle / exécution du contrat / intérêt légitime (ne publier les demandes qu'à des sociétés vérifiées) | Google Firebase (hébergement, authentification) ; **Brevo** (e-mails) ; le **client** avec lequel la société conclut (nom de la société, nom, téléphone et e-mail de la personne de contact). Le relevé quotidien et les factures mensuelles ne sont lisibles depuis l'application par personne, administration comprise : seules les fonctions serveur y accèdent, et la validation d'une facture est réservée à un Super Admin de ShieldOne | Voir la note sur la localisation des services Google ci-dessous ; Brevo : France | **Aucune suppression automatique à ce jour** ; aucune durée n'est appliquée au relevé quotidien ni aux factures mensuelles ; l'acceptation des conditions est conservée sans limite, comme les autres preuves d'acceptation ; réglage des e-mails de nouvelles demandes : conservé avec la fiche de la société ; trace de ses modifications au journal de l'administration : **aucune durée à ce jour** | | **R17** | **Mesure anonyme de l'utilisation du site public** *(ajouté le 26 septembre 2026, avant sa mise en service)* | Visiteurs des pages publiques de shieldone.ch (hors application et hors centre d'aide) ; dans l'application web et sur la page de demande de shieldone.ch (`/demande`), personnes qui s'inscrivent ou déposent une demande ShieldOne Services **avant toute connexion** | Affichage de page (page ramenée à la liste des pages du site), source ramenée au **nom de domaine**, paramètres de campagne « utm » sous forme courte et normalisée, clics sur des éléments identifiés à l'avance, durée d'affichage visible ; dans l'application web avant connexion, étapes de l'inscription et du formulaire de demande, avec leur durée, et abandon ; sur la page de demande, mêmes étapes du formulaire de demande, avec leur durée, et abandon ; **empreinte du jour** calculée à partir de l'adresse IP et du navigateur au moyen d'une valeur secrète tirée au hasard, renouvelée au moins chaque jour, gardée en mémoire et **jamais écrite**. **Aucun cookie, aucun stockage sur l'appareil, aucune adresse IP ni donnée de navigateur écrite en base, aucun texte libre.** Rien n'est envoyé si le navigateur émet un signal GPC ou DNT. Le comptage de la page d'accueil (R5) coexiste avec cette mesure | Comprendre la fréquentation du site et les parcours d'inscription et de demande, pour les améliorer | Intérêt légitime | Google Firebase (hébergement, fonctions serveur à Zurich) ; journaux techniques de la plateforme : voir la note relative à R17 et R18 | — (CH) ; journaux techniques de la plateforme : voir R4 et R7quater | Événements : supprimés par une tâche automatique quotidienne au terme de **13 mois**, une fois leur mois résumé ; statistiques résumées, sans aucun identifiant : **aucune durée n'est appliquée** | | **R18** | **Mesure d'utilisation liée au compte personnel ; mesure des parcours professionnels sans identifiant ; relance d'une inscription non terminée** *(ajouté le 26 septembre 2026, avant sa mise en service)* | Titulaires d'un compte personnel ; représentants des sociétés de sécurité qui répondent à une demande ou activent leur abonnement ; représentants des organismes de formation qui publient un cours, acceptent une demande ou valident une participation dans ShieldOne Training ; personnes qui commencent une inscription par e-mail sans la terminer | **Mesure liée au compte personnel**, sur une **liste fermée** d'événements et de propriétés, sans texte libre : étapes atteintes et abandonnées de l'inscription, du formulaire de demande ShieldOne Services et de l'espace personnel, avec leur durée ; événements enregistrés par le serveur après succès (compte créé, adresse vérifiée, demande créée et publiée avec service et canton, offre retenue et conclusion avec service, canton, mode de tarif et **prix lus par le serveur** ; demande d'inscription à un cours ShieldOne Training, avec le seul type et le seul canton du cours, au plus une fois par 24 heures pour un même cours, R22) ; identifiant de compte. **Parcours professionnels** (réponse d'une société à une demande, avec le prix proposé ; activation de l'abonnement, avec le nombre d'agents) : **aucun identifiant de personne ni de société**. Les gestes d'un organisme de formation dans ShieldOne Training (publication d'un cours, acceptation d'une demande, participation validée, avec le seul type et le seul canton du cours et, pour une participation, l'indication d'un certificat vérifié ou non) sont comptés de même, **sans identifiant de personne ni d'organisme** (R21). Aucune étape de ShieldOne Training, du profil pro ni de ShieldOne Jobs n'est mesurée depuis l'appareil de la personne ; celles qui sont comptées le sont par les serveurs. L'activité de terrain des utilisateurs professionnels n'est pas mesurée. **Opposition** : identifiant de compte, tracée au journal de l'administration. **Relance** : adresse e-mail enregistrée au clic « Continuer » (jamais pendant la frappe), langue, dates, empreintes des deux jetons de reprise et de désinscription (jamais l'adresse dans un lien), état de la relance ; compteur par adresse ; **empreinte de l'adresse IP** (IPv6 : préfixe /48), **sans valeur secrète** — elle permet, par calcul, de retrouver l'adresse IP ou son préfixe —, avec un compteur horaire | Comprendre et améliorer l'espace personnel, ShieldOne Services, ShieldOne Training et l'activation de l'abonnement ; aider la personne à reprendre une inscription commencée ; protéger ce parcours contre les abus | Intérêt légitime ; opposition par écrit à contact@shieldone.ch ; relance : refus par le lien de désinscription | Google Firebase (hébergement, fonctions serveur à Zurich) ; **Brevo** (relance : adresse et contenu de l'e-mail ; la trace d'envoi ne garde que le domaine de l'adresse). L'outil de l'administration ne montre que des statistiques ; les prix n'y figurent que résumés par service, canton et mode de tarif, masqués sous trois valeurs | — (CH) ; Brevo : France | Événements : supprimés par une tâche automatique quotidienne au terme de **13 mois**, une fois leur mois résumé ; effacés à la suppression du compte et à l'opposition ; statistiques résumées, sans aucun identifiant : **aucune durée n'est appliquée**. Opposition : effacée à la suppression du compte. Adresse d'une inscription non terminée : effacée dès qu'un compte est créé à cette adresse, et au plus tard par une tâche automatique quotidienne **30 jours** après le clic « Continuer » ; copies de sauvegarde : 98 jours. Empreinte d'adresse IP et compteur : **aucune durée n'est appliquée à ce jour** | | **R19** | **ShieldOne Local — fil, publications d'habitants, signalements, masquages, lieux (zones d'intérêt)** *(ajouté le 30 septembre 2026 ; nom du lieu et plafond porté à 20 le 1er octobre 2026 ; adresse précise d'un lieu, sur choix de la personne, le 1er octobre 2026 ; durées de conservation des publications, des signalements et des blocages levés, décompte anonyme des publications effacées et vérification de l'adresse choisie auprès de swisstopo, le 2 octobre 2026 ; conditions de ShieldOne Local intégrées aux conditions d'utilisation de l'espace personnel (article 17) le 5 octobre 2026 ; pastille météo de l'accueil, calculée à partir du premier lieu, le 5 octobre 2026)* | Titulaires d'un compte personnel qui lisent le fil de ShieldOne Local, publient, signalent, masquent un auteur ou enregistrent un lieu ; à titre transitoire, une personne qu'une publication non conforme viserait malgré l'interdiction, le temps que la modération la refuse (la publication n'est jamais visible avant cette décision) ; une personne dont l'adresse serait enregistrée pour un lieu sans son accord, malgré l'interdiction de l'article 17.6.2 des *Conditions d'utilisation de l'espace personnel — ShieldOne* | **Lecture du fil** : identifiant de compte, servant uniquement à écarter les auteurs masqués par l'appelant, et critère de tri choisi (canton, commune ou zone). **Publication d'un habitant** : pseudonyme choisi (jamais le nom complet ni une coordonnée), titre, texte, commune officielle, catégorie, identifiant de compte de l'auteur — **conservé côté ShieldOne, jamais montré**, ni aux autres utilisateurs ni au public —, statut, dates de soumission et de publication. **Signalement** : identifiant de compte du signalant — **jamais montré**, ni à l'auteur ni au modérateur —, motif choisi dans une liste fermée, texte libre facultatif (300 caractères au plus). **Masquage** : identifiants des auteurs masqués par la personne (jusqu'à 200), propres à son compte. **Lieu** (zone d'intérêt) : nom choisi par la personne (1 à 40 caractères, sans adresse ni coordonnée), point **arrondi à environ 500 m** — sur l'appareil avant tout envoi lorsque le lieu est placé par une position ou une localité — ou, si la personne choisit une adresse, **l'adresse précise** (libellé « rue numéro, NPA localité ») et son **point exact à six décimales**, dont le serveur déduit le point arrondi ; rayon (1 à 50 km), commune de référence déduite par le serveur (jusqu'à 20 lieux par compte). **Pastille météo de l'accueil** : à chaque ouverture du fil, le serveur lit le **point arrondi à environ 500 m** du premier lieu enregistré par la personne, jamais son adresse précise ni son point exact. Il en déduit la station de mesure de MétéoSuisse la plus proche, à 20 km au plus, dont la mesure date de moins de 40 minutes. Seuls le **nom de cette station** et sa **température** sont rendus à la personne, jamais le point, le nom du lieu ni la commune. **Rien n'est enregistré** pour la personne, ni la station ni le calcul. Sans station à portée ou sans mesure récente, aucune température n'est affichée. **Recherche d'adresse** : texte tapé (3 à 80 caractères), transmis par le serveur à swisstopo et non conservé ; à l'enregistrement d'un lieu à une adresse choisie, **libellé de cette adresse** (200 caractères au plus), soumis de nouveau par le serveur à swisstopo, sans le point ni aucun identifiant — l'adresse n'est retenue que si swisstopo rend le même libellé au même point ; compteur journalier des recherches, vérifications comprises, lié au compte (150 au plus). **Modération** : trace de chaque décision (publier, refuser, corriger, retirer, classer un signalement, bloquer ou débloquer un auteur) au journal de l'administration de ShieldOne — identifiant de la publication concernée, identifiant et adresse e-mail de la personne de ShieldOne qui a agi, motif lorsqu'il est exigé — **jamais l'identifiant de l'auteur ni celui du signalant** ; la trace d'un blocage, et celle d'une levée décidée depuis la liste des auteurs bloqués (à la place, pour cette levée, de l'identifiant de la publication), portent une **clé calculée à partir de l'identifiant de compte de l'auteur** (empreinte SHA-256) : elle n'est pas anonyme, qui connaît l'identifiant retrouvant la clé. **Liste des auteurs bloqués**, accessible à la seule administration de ShieldOne : pour chaque auteur bloqué, cette clé, le pseudonyme retenu, le motif et la date du blocage — jamais l'identifiant de compte. **Décisions de modération enregistrées avec leur objet** : sur la publication, statut, motif d'un refus ou d'un retrait, identifiant de la personne de ShieldOne qui a décidé et dates ; sur le signalement, issue, date et identifiant de la personne de ShieldOne qui l'a classé ; sur la fiche de l'auteur, blocage en cours (motif, identifiant de la personne de ShieldOne qui a décidé, date) et dernier blocage levé (les mêmes, avec la date, l'auteur et le motif de la levée). **Décompte des publications effacées** : nombre de publications par mois, par commune et par catégorie, mises en ligne ou non — ni texte, ni titre, ni pseudonyme, ni identifiant de compte ou de publication. **Acceptations distinctes des *Conditions d'utilisation de ShieldOne Local*, enregistrées avant leur intégration aux conditions d'utilisation de l'espace personnel** (depuis, leur acceptation est celle de R12 ; aucune nouvelle acceptation distincte n'est enregistrée) : identifiant de compte, version et empreinte du texte présenté, date et heure fixées par le serveur — état courant au profil personnel et historique de chaque acceptation, conservés. | Afficher le fil de ShieldOne Local ; recueillir une publication d'habitant, la faire examiner par ShieldOne avant toute mise en ligne, la publier sous pseudonyme, la corriger ou la retirer ; traiter les signalements et les masquages ; retenir les lieux pour le tri du fil ; afficher sur l'accueil la température relevée par la station de MétéoSuisse la plus proche du premier lieu ; placer un lieu à l'adresse choisie par la personne ; lui proposer des adresses et vérifier auprès de swisstopo celle qu'elle choisit ; bloquer, en cas de manquement, l'auteur d'une publication ; conserver la preuve des acceptations distinctes des conditions de ShieldOne Local enregistrées avant leur intégration aux conditions de l'espace personnel ; avant d'effacer une publication à son terme, en tenir un décompte anonyme (nombre par commune, par catégorie et par mois) | Exécution du contrat (*Conditions d'utilisation de l'espace personnel — ShieldOne*, article 17) ; intérêt légitime (modération, sécurité du fil ; preuve de l'acceptation ; décompte anonyme des publications effacées) ; pour l'enregistrement d'un lieu, le choix de la personne de l'enregistrer | Google Firebase (hébergement, fonctions serveur). **Tous les utilisateurs de ShieldOne Local** reçoivent une publication d'habitant une fois publiée, sous le pseudonyme de son auteur — jamais son identité ni son identifiant. En interne, la file de modération n'est accessible qu'à l'administration de ShieldOne. **swisstopo** (Office fédéral de topographie, service de recherche d'adresses) : le texte tapé et, à l'enregistrement d'un lieu à une adresse choisie, le libellé de cette adresse, sans identifiant de compte, sans adresse IP de la personne et sans point. L'adresse précise n'est rendue qu'à son titulaire ; aucune fonction d'administration, de modération ni de statistique ne la lit. **MétéoSuisse** ne reçoit aucune donnée d'utilisateur : ShieldOne collecte ses mesures pour l'ensemble du service (R20), sans lien avec une personne. La station déduite du premier lieu n'est rendue qu'à son titulaire. Le décompte des publications effacées n'est lisible depuis l'application par personne, administration comprise | Voir la note sur la localisation des services Google ci-dessous ; fonctions serveur en région de Zurich (`europe-west6`). swisstopo : service de la Confédération, diffusé par un réseau de diffusion d'une société établie aux États-Unis (relevé le 1er octobre 2026) ; le texte tapé et le libellé de l'adresse choisie peuvent transiter hors de Suisse — voir « Points en suspens » | **Publication** : affichée jusqu'à l'échéance propre à sa catégorie (de 48 heures à 30 jours), puis **effacée**, avec les décisions de modération qu'elle porte, par une tâche planifiée quotidienne une fois passés **30 jours** depuis sa mise en ligne — ou depuis sa soumission si elle n'a jamais été mise en ligne (refusée, ou encore en attente d'examen : elle est alors effacée sans avoir été examinée) ; un reste est repris la nuit suivante. Une publication dont l'auteur est bloqué est effacée au même terme. **Anonymisée** à la suppression du compte de son auteur, quel que soit son statut, puis effacée au même terme. **Décompte des publications effacées** : écrit dans la même opération que l'effacement ; **aucune durée n'est appliquée** (il ne porte aucun identifiant). **Signalement** : effacé, avec la décision qui l'a classé, par la même tâche **12 mois** (mois calendaires) après son classement, ou après sa création s'il n'a jamais été classé ; un signalement encore ouvert lorsque la publication visée est effacée est classé dans la même opération, sans décideur, puis effacé 12 mois plus tard ; anonymisé (s'il est encore ouvert) ou effacé (s'il est déjà traité) à la suppression du compte de son auteur. **Blocage** : un blocage en cours est conservé tant qu'il dure ; le dernier blocage levé est effacé par la même tâche **12 mois** au plus tard après sa levée. Une publication ou un signalement dont la date est absente ou invalide n'est pas effacé ; la tâche le compte au journal technique pour examen. **Pseudonyme retenu, blocage, masquages, compteur journalier, lieux** : durée du compte ; effacés à sa suppression. **Lieux et adresse précise** : durée du compte, ou jusqu'au retrait par la personne. **Compteur de recherches d'adresse** : remplacé chaque jour de recherche, effacé avec le compte. **Texte tapé et libellé soumis pour vérification** : non conservés, en dehors de l'adresse retenue avec le lieu. **Pastille météo** : la station déduite du premier lieu et la température rendue ne sont pas conservées par ShieldOne ; elles sont recalculées à chaque ouverture du fil. **Trace d'une décision de modération** au journal de l'administration : **aucune durée à ce jour** ; elle ne nomme ni l'auteur ni le signalant, mais celle d'un blocage ou de sa levée peut porter la clé calculée à partir de l'identifiant de compte de l'auteur, et elle n'est pas effacée à la suppression du compte ; elle n'est pas effacée avec la publication, le signalement ou le blocage qu'elle concerne. **Historique des acceptations distinctes des conditions de ShieldOne Local (antérieures à leur intégration)** : **aucune durée**, conservé y compris après la suppression du compte, parce qu'il constitue la preuve de l'acceptation (même régime que l'historique des acceptations de l'espace personnel) ; état courant : supprimé avec le profil | | **R20** | **ShieldOne Local — collecte des sources officielles** *(ajouté le 30 septembre 2026 ; mesures de température de MétéoSuisse ajoutées le 5 octobre 2026)* | Personnes citées dans un communiqué de police retenu par ShieldOne, notamment une personne interpellée, dans la seule mesure où une phrase gabarit en tire un fait ; aucune personne concernée identifiée pour les autres sources (avis météorologiques, mesures de température de MétéoSuisse, conditions du trafic routier, perturbations des transports publics), qui ne portent normalement aucune donnée personnelle | Pour un communiqué de police retenu : le **type de fait** reconnu par un gabarit fixe — fait de sécurité (accident, disparition, danger, fermeture, appel à témoins…) ou fait criminel que la police a elle-même rendu public (brigandage, agression, cambriolage, vol, interpellation) —, l'indication qu'une interpellation a eu lieu ou qu'un appel à témoins est lancé et, **pour une interpellation, son motif**, choisi dans une **liste fermée de libellés fixes** (stupéfiants, infraction routière, après un incendie, escroquerie, dommages à la propriété, personne recherchée), un seul à la fois, jamais lorsque ShieldOne reconnaît dans le titre une infraction sexuelle, un décès ou des blessures graves ; **une interpellation dont le titre ne fait reconnaître qu'un motif lié au statut migratoire de la personne n'est pas reprise ; aucun libellé de motif ne désigne ce statut, et pour tout communiqué repris, seule est conservée une adresse du communiqué qui ne reprend pas les mots de ce statut reconnus par ShieldOne** (reconnaissance lexicale du titre et de l'adresse, qu'une formulation autre peut déjouer) ; la **commune ou le canton** reconnu par le référentiel des communes de Suisse romande ; la **date** du communiqué ; l'**adresse du communiqué**, telle que la police la publie, qui reprend chez certaines polices des mots de son titre — **jamais le texte du communiqué, jamais une photo ; la phrase ne dit jamais le nom, l'âge, la nationalité, l'origine, le nombre ni la description des personnes en cause**. **Une interpellation et son motif, comme un autre fait criminel, rapportés à une commune et à une date, sont des données sur des poursuites ou sanctions pénales ou administratives (art. 5 let. c ch. 5 nLPD), donc des données sensibles, dès lors qu'une personne est identifiable**, par exemple dans une petite commune ou par rapprochement avec le communiqué lié. Le titre et la description du communiqué source sont lus une seule fois par les serveurs de ShieldOne pour reconnaître ces éléments, **puis jetés : ils ne sont pas enregistrés**. Pour les autres sources : les informations qu'elles publient elles-mêmes (avis, perturbation, fermeture), sans recherche ni conservation de donnée personnelle par ShieldOne | Informer les utilisateurs de ShieldOne Local de faits de sécurité publique et de conditions locales, sans reprendre le contenu protégé des communiqués sources ; arrêter la reprise des communiqués d'un canton sur sa demande | Intérêt légitime (information du public sur des faits de sécurité, de circulation et de conditions météorologiques). Pour les faits criminels et les interpellations, faits rendus publics par la police elle-même : **intérêt prépondérant (art. 31 nLPD) [À VALIDER PAR L'AVOCAT]** | Google Firebase (hébergement, fonctions serveur). Les sources elles-mêmes (MeteoAlarm, MétéoSuisse via data.geo.admin.ch, OFROU et transports publics via opentransportdata.swiss, polices cantonales) **ne reçoivent aucune donnée d'utilisateur** : ShieldOne seule les interroge, par une requête de lecture standard | Voir la note sur la localisation des services Google ci-dessous ; fonctions serveur en région de Zurich (`europe-west6`) | La **dernière copie obtenue d'une source** est remplacée à chaque collecte réussie qui aboutit ; en cas d'échec, la copie précédente est conservée jusqu'à la collecte suivante qui aboutit. Une phrase tirée d'un communiqué de police n'est conservée que dans cette copie et dans le fil préparé qui en est tiré, recalculé en principe toutes les deux minutes sans les phrases de plus de sept jours : elle n'est plus affichée au-delà du septième jour suivant la date du communiqué, en sort à la première collecte réussie après ce terme, et cesse d'être affichée dès que la reprise de son canton est coupée ; copies de sauvegarde de la base : 98 jours. Le titre et la description bruts d'un communiqué source **ne sont jamais enregistrés** : rien n'est à purger de ce côté | | **R21** | **ShieldOne Training — organismes de formation : validation, compte, suspension, cours publiés** *(ajouté le 11 octobre 2026 ; le service est ouvert depuis le 10 octobre 2026)* | Représentants et personnes de contact des organismes de formation validés par ShieldOne, y compris le titulaire d'une raison individuelle dont le nom est celui de l'organisme ; personnes de ShieldOne qui valident, suspendent ou rétablissent un organisme (identifiant) | **Fiche de l'organisme**, complétée par ShieldOne lors de l'appel de validation : nom de l'organisme, canton, adresse e-mail (contact et connexion) et, facultatifs, le nom de la personne de contact, le téléphone et le site web ; état (en validation, validé, suspendu), dates de création et de validation, identifiant de la personne de ShieldOne qui a validé ; pendant la création du compte, une réservation technique (adresse e-mail, valeur aléatoire, date). **Compte d'accès** : compte du service d'authentification (adresse e-mail, empreinte du mot de passe tenue par ce service, marque technique du compte) ; fiche technique du compte (identifiants du compte et de l'organisme, adresse e-mail, dates de création, d'émission du dernier lien et de définition du mot de passe) ; **lien de définition du mot de passe**, à usage unique et valable 24 heures : enregistré sous l'empreinte du jeton, jamais le jeton lui-même, qui ne figure que dans l'e-mail, avec les identifiants du compte et de l'organisme et les dates de création, d'expiration et d'utilisation ; compteur anti-abus de la page de définition du mot de passe : empreinte calculée à partir de l'adresse IP transmise, **sans valeur secrète** et tronquée — elle **permet, par calcul, de retrouver l'adresse IP** —, heure et nombre d'essais, rattachés à aucune personne. **Suspension et rétablissement** : motif écrit en cours, motif du rétablissement, dates, identifiant de la personne de ShieldOne qui a agi, et **historique de chaque suspension et de chaque rétablissement** (geste, date, identifiant de la personne de ShieldOne, motif) ; le motif est un texte libre. **Acceptation des *Conditions de ShieldOne Training*** : sur la fiche, version et empreinte du texte accepté, date et heure fixées par le serveur, identifiant du compte qui a accepté ; dans un historique tenu à part, une entrée par acceptation d'une version nouvelle (partie, identifiants du compte et de l'organisme, version, empreinte, date). **Cours publiés** : titre, description, type, dates, horaire, lieu, canton, prix affiché, nombre de places et places tenues, prérequis, certificat et son intitulé ; statut ; dates de publication, de modification et d'annulation, et identifiant du compte de l'organisme qui a fait chacun de ces gestes. **Journal de l'administration de ShieldOne** : trace de la validation, de la création du compte, de l'envoi d'un lien, de la suspension, du rétablissement et de l'avis aux agents (identifiant de l'organisme, issue de l'envoi, **longueur du motif, jamais le motif**), avec l'identifiant et l'adresse e-mail de la personne de ShieldOne qui a agi | Valider les organismes admis à publier des cours ; leur ouvrir un compte d'accès par un lien de définition du mot de passe ; publier leurs cours au catalogue ; transmettre leurs coordonnées à un agent dont la demande est acceptée ; leur adresser les avis de ShieldOne Training (nouvelle demande, sans l'identité de l'agent ; place libérée) ; suspendre ou rétablir un organisme et garder le motif de chaque geste ; conserver la preuve de l'acceptation des conditions ; limiter les abus de la page de définition du mot de passe | Démarche précontractuelle (validation) / exécution du contrat (*Conditions de ShieldOne Training*) / intérêt légitime (n'ouvrir le catalogue qu'à des organismes vérifiés ; preuve de l'acceptation et des motifs de suspension ; sécurité) | Google Firebase (hébergement, authentification, fonctions serveur) ; **Brevo** (e-mails à l'organisme). **Titulaires d'un compte personnel** : au catalogue, le nom et le site de l'organisme et le contenu de ses cours ; à un agent dont l'inscription est acceptée à un cours maintenu, l'adresse e-mail, le nom de la personne de contact et le téléphone de l'organisme, dans l'application et dans l'e-mail d'acceptation ; aux agents prévenus d'une suspension, le nom de l'organisme, **jamais le motif**. Le motif d'une suspension n'est lisible que dans la console de l'administration de ShieldOne, ni par l'organisme ni par les agents. Ces données ne sont lisibles ni modifiables depuis l'application par personne : seules les fonctions serveur y accèdent | Voir la note sur la localisation des services Google ci-dessous ; fonctions serveur en région de Zurich (`europe-west6`). Authentification : service sans réglage régional, **non couvert par l'hébergement suisse**. Brevo : France | **Aucune suppression automatique, et aucune fonction de suppression d'un organisme ni de son compte n'existe à ce jour.** Fiche, compte d'accès et fiche technique, liens de définition du mot de passe (y compris utilisés ou expirés), cours (y compris passés ou annulés), motifs et historique des suspensions : **aucune durée n'est appliquée**. Acceptation des conditions : l'état courant est conservé avec la fiche ; l'historique n'a **aucune durée appliquée**, parce qu'il constitue la preuve de l'acceptation. Compteur anti-abus : **aucune durée n'est appliquée**. Traces au journal de l'administration : **aucune durée à ce jour**. Trace des e-mails envoyés : R10 ②. Mesure des gestes de l'organisme, sans identifiant : R18. Compteurs par compte : R4 ②. Connexion du compte d'accès et « mot de passe oublié » : R3 et R4 ③ | | **R22** | **ShieldOne Training — demandes et inscriptions des agents** *(ajouté le 11 octobre 2026 ; le service est ouvert depuis le 10 octobre 2026)* | Titulaires d'un compte personnel, non rattaché à une société, qui consultent le catalogue de ShieldOne Training, en acceptent les conditions et demandent à s'inscrire à un cours ; personne de l'organisme qui valide une participation (identifiant de compte) | **Consultation du catalogue** : les filtres choisis (canton, dates, type) et les cours consultés **ne sont pas enregistrés** ; seuls s'appliquent les compteurs par compte de R4 ②. **Acceptation des *Conditions de ShieldOne Training*** : avec le profil personnel, version et empreinte du texte accepté, date et heure fixées par le serveur, identifiant du compte ; dans un historique tenu à part, une entrée par acceptation d'une version nouvelle (partie, identifiant du compte, version, empreinte, date). **Inscription** — une fiche par cours et par agent, sous un identifiant technique formé de l'identifiant du cours et d'une empreinte calculée, **sans valeur secrète**, à partir de l'identifiant du cours et de celui du compte : identifiants du cours, de l'organisme et du compte de l'agent ; **copie des prénom et nom** du profil personnel, s'ils sont renseignés, **et de l'adresse e-mail** du compte (y compris une adresse de relais Apple), lus par le serveur au moment de la demande, jamais transmis par l'appareil, et refaits à chaque nouvelle demande pour ce cours ; état (demandée, acceptée, refusée, annulée par l'agent, annulée avec le cours, participation validée, cours non suivi) ; dates de la demande et de la dernière modification ; historique des changements d'état (les 20 derniers au plus : état, date, et s'il vient de l'agent ou de l'organisme, sans nom ni identifiant) ; à l'acceptation, le prix affiché à ce moment ; à la validation de la participation, sa date, l'identifiant du compte de la personne de l'organisme qui l'a faite et, pour un cours annoncé avec certificat, la mention « certificat vérifié » et son intitulé ; date d'examen interne de l'effacement, date de l'effacement de la copie . Pour le type de cours « Découverte du tir », l'attestation de majorité sur l'honneur n'est **pas enregistrée**. **E-mails à l'agent** : adresse copiée lors de sa dernière demande pour le cours, contenu de l'avis (organisme ; titre, dates et lieu du cours ; prix ; à l'acceptation, contact de l'organisme ; refus ; participation validée, avec l'intitulé du certificat le cas échéant, ou cours non suivi ; annulation du cours ; à une suspension, cours devenus indisponibles, sans motif). **Mesure** : la demande d'inscription, liée à l'identifiant du compte, avec le seul type et le seul canton du cours, au plus une fois par 24 heures pour un même cours (R18) | Montrer le catalogue ; transmettre la demande à l'organisme qui publie le cours ; permettre à l'agent de suivre et d'annuler ses demandes et inscriptions ; lui écrire à leur sujet ; garder le prix qui vaut pour lui, qui ne monte jamais après son acceptation ; effacer, chez l'organisme, la copie de son identité après un refus ou une annulation ; conserver la preuve de l'acceptation des conditions ; comprendre l'usage du service | Exécution du contrat (*Conditions d'utilisation de l'espace personnel*, *Conditions de ShieldOne Training*), y compris pour la transmission de l'identité à l'organisme dès la demande ; intérêt légitime (preuve de l'acceptation ; respect des *Conditions de ShieldOne Training* ; effacement de la copie chez l'organisme ; mesure, avec opposition selon R18) | Google Firebase (hébergement, authentification, fonctions serveur) ; **Brevo** (e-mails à l'agent ; la trace d'envoi ne garde que le domaine de son adresse, R10 ②). **Organisme de formation qui publie le cours** : dès la demande, la copie des prénom, nom et adresse e-mail, l'état de l'inscription, les dates de la demande et de la dernière modification, l'identifiant technique de l'inscription, la mention « certificat vérifié » le cas échéant et, une fois l'inscription acceptée, le prix qui vaut pour l'agent ; **jamais** l'identifiant du compte ni l'historique de l'inscription. L'organisme traite ce qu'il reçoit **sous sa propre responsabilité** (*Conditions de ShieldOne Training*, article 10.3). Les e-mails adressés à l'organisme ne contiennent pas l'identité de l'agent. **Aucune société cliente de ShieldOne**, par exemple un employeur, n'a accès aux demandes ni aux inscriptions, et rien n'en est lu par ShieldOne Services ni par le logiciel professionnel. Ces données ne sont lisibles ni modifiables depuis l'application : seules les fonctions serveur y accèdent, et elles ne rendent à chaque agent que ses propres inscriptions, et à chaque organisme que celles de ses cours | Voir la note sur la localisation des services Google ci-dessous ; fonctions serveur en région de Zurich (`europe-west6`). Authentification : service sans réglage régional, **non couvert par l'hébergement suisse**. Brevo : France. **Organisme de formation** : ShieldOne enregistre pour chaque organisme un canton suisse ; elle ne contrôle pas où l'organisme traite ce qu'il reçoit, qui relève de sa responsabilité | **Copie des prénom, nom et adresse e-mail transmise à l'organisme, pour une demande refusée ou une demande ou inscription annulée** (par l'agent ou avec le cours) : **vidée** par une tâche automatique qui s'exécute chaque nuit, **30 jours après le dernier jour du cours** ; à défaut de date de cours lisible, 30 jours après la dernière modification de l'inscription ; sans aucune date lisible, au premier passage de la tâche ; un reste est repris la nuit suivante. ShieldOne active cette tâche avant le premier terme possible, le 9 novembre 2026 ; jusqu'à son activation, aucune copie n'est effacée automatiquement. Elle n'est pas effacée à la suppression du compte. **Copie pour une inscription acceptée, dont la participation a été indiquée, ou une demande restée en attente** : **aucune suppression automatique n'est appliquée à ce jour**, y compris après la suppression du compte. **Inscription elle-même** (état, historique, dates, prix retenu à l'acceptation, participation, certificat, identifiant de la personne de l'organisme qui a validé, date d'effacement) : **aucune suppression automatique n'est appliquée à ce jour** ; elle reste rattachée à l'identifiant du compte, y compris après la suppression du compte, et l'adresse e-mail copiée continue alors de recevoir les avis liés à l'inscription (annulation du cours, suspension de l'organisme, participation). **Acceptation des conditions** : l'état courant est supprimé avec le profil personnel ; l'historique n'a **aucune durée appliquée** et n'est pas effacé par la suppression du compte, parce qu'il constitue la preuve de l'acceptation. **Mesure** : R18. **Trace des e-mails envoyés** : R10 ②. **Compteurs par compte** : R4 ② | | **R23** | **Profil pro — fiche du parcours d'agent, vérification par ShieldOne, visibilité société par société** *(ajouté le 11 octobre 2026 ; le service est ouvert depuis le 10 octobre 2026)* | Titulaires d'un compte personnel qui tiennent un profil pro ; personnes de ShieldOne qui vérifient ou consultent un profil (identifiant et adresse e-mail) | **Fiche du profil** (un document par personne, sous l'identifiant de son compte) : pour chacune de neuf rubriques facultatives, la valeur déclarée, son niveau (déclaré ou vérifié par ShieldOne), la date de vérification, l'empreinte de la valeur vérifiée et la liste des sociétés à qui la rubrique est montrée (200 au plus) — **coordonnées** (téléphone à forme internationale, adresse e-mail, code postal, localité), **cantons**, **langues**, **qualifications** (intitulés), **brevet fédéral** (année), **premiers secours** (niveau, validité), **permis de conduire** (catégories), **attestation d'arme** (canton, date de validité, jamais de numéro), **expérience** (postes). **CV** : fichier PDF de 6 Mio au plus, dans l'espace de stockage, et sa référence ; la fonction serveur qui le reçoit existe, l'application ne la propose pas à la date de la présente version. Le prénom et le nom ne sont pas dans le profil : ils viennent du profil personnel (R12). **Journal de l'administration de ShieldOne** : trace de chaque consultation, vérification et retrait de vérification (acte, personne de ShieldOne, compte du profil, rubrique), **jamais la valeur lue** | Permettre au titulaire de présenter son parcours et de décider de ce qu'une société en voit (geste que l'application ne propose pas encore) ; faire vérifier une valeur par ShieldOne à sa demande ; permettre à une société à qui une rubrique est montrée de la lire dans le cadre d'une candidature (R24) ; justifier chaque consultation et chaque vérification | Exécution du contrat (*Conditions d'utilisation de l'espace personnel*) pour tenir et faire vérifier le profil ; choix de la personne pour ce qu'une société en voit ; intérêt légitime (traçabilité des consultations et des vérifications) | Google Firebase (hébergement, authentification, fonctions serveur, stockage). **Société à qui une rubrique est montrée**, par une candidature en cours : les champs publics des seules rubriques remplies et montrées à cette société, avec leur niveau, jamais le numéro d'une attestation d'arme (seule sort sa date de validité, échue et déclarée), la liste des autres sociétés ni la référence du CV ; aucune société ne peut ouvrir le CV. Une société ne voit plus rien dès que la candidature est close. **ShieldOne** peut tout lire sauf le CV, y compris ce qui n'est montré à aucune société, uniquement pour vérifier ; chaque consultation est journalisée. Ces données ne sont lisibles ni modifiables depuis l'application par personne, administration comprise : seules les fonctions serveur y accèdent | Voir la note sur la localisation des services Google ci-dessous ; fonctions serveur et stockage en région de Zurich (`europe-west6`). Authentification : service sans réglage régional, **non couvert par l'hébergement suisse**. Aucun autre destinataire hors de Suisse | **Aucune suppression automatique pour inactivité.** Le profil et le CV sont effacés à la suppression du compte personnel (déclencheur de suppression, reprise quotidienne en cas d'échec) ; un CV supprimé ou remplacé passe en corbeille technique 90 jours, restaurable par les seuls administrateurs techniques, puis disparaît ; la fiche du profil suit les copies de sauvegarde de la base (98 jours). **Trace au journal de l'administration** : aucune durée n'est appliquée à ce jour ; elle n'est pas effacée à la suppression du compte. Compteurs par compte : R4 ② | | **R24** | **ShieldOne Jobs — candidatures des titulaires d'un compte personnel** *(ajouté le 11 octobre 2026 ; le service est ouvert depuis le 10 octobre 2026)* | Titulaires d'un compte personnel qui postulent à une offre d'emploi ; représentants des sociétés clientes qui lisent une candidature (identifiant de compte du manager) | **Candidature** (un document par candidature, à la racine) : identifiants de la société, de l'offre et du compte du candidat ; état (envoyée, lue, en discussion, embauche confirmée, non retenue, retirée, offre terminée) ; dates de dépôt, de dernière modification et de clôture, motif de la clôture ; déclaration d'avoir 18 ans révolus ; **message** facultatif (1 000 caractères au plus, texte libre). **Rien d'autre n'est copié** : ni adresse e-mail, ni téléphone, ni profil pro, ni document. **Lecture par la société** : dans l'espace de la société, une trace par lecture ou geste (identifiant de la candidature, acte, identifiant du compte du manager et son nom, date), **jamais la valeur lue ni l'identifiant du candidat**. **Signalement d'une offre** : la porte serveur existe, aucun écran de l'application ne l'expose ; elle n'est pas décrite ici. **E-mails au candidat** : adresse de connexion du compte (jamais l'adresse du profil), titre de l'offre et nom de la société ; la trace d'envoi ne garde que le domaine de l'adresse | Transmettre la candidature à la société qui a publié l'offre ; permettre au candidat de la suivre et de la retirer ; permettre à la société de la lire, de la refuser, de la marquer en discussion ou de confirmer l'embauche ; informer le candidat du refus ou de la fin de l'offre ; justifier chaque lecture par la société | Exécution du contrat (*Conditions d'utilisation de l'espace personnel*, article 18) ; intérêt légitime (traçabilité des lectures) | Google Firebase (hébergement, authentification, fonctions serveur) ; **Brevo** (e-mails au candidat). **Société qui a publié l'offre** : prénom et nom du candidat (lus dans son profil personnel au moment de la lecture), message, état et dates, et les rubriques de son profil pro qu'il lui a montrées (R23) ; seules les personnes de la société qui ont le droit de recruter ; la société les traite **sous sa propre responsabilité** et n'est pas sous-traitant de ShieldOne pour cela. **Aucune autre société** n'en reçoit, hors la restitution de ses propres données à la société, à la fin de son contrat (identifiant du compte du candidat, offre, état, dates, message, closes comprises, sans le profil pro) ; aucun administrateur de ShieldOne n'a de geste sur une candidature, et ShieldOne ne lit pas le profil pour trier, classer ou recommander. Ces données ne sont lisibles ni modifiables depuis l'application : seules les fonctions serveur y accèdent | Voir la note sur la localisation des services Google ci-dessous ; fonctions serveur en région de Zurich (`europe-west6`). Authentification : service sans réglage régional, **non couvert par l'hébergement suisse**. Brevo : France. **Société** : ShieldOne ne contrôle pas où la société traite ce qu'elle reçoit, qui relève de sa responsabilité | **Candidature et traces de sa lecture** : effacées par une tâche automatique qui s'exécute chaque nuit, **6 mois** après la clôture de la candidature ou, si elle est plus proche, de l'offre ; ShieldOne active cette tâche avant le premier terme possible, le 10 avril 2027 ; jusqu'à son activation, aucune candidature n'est effacée automatiquement ; une candidature dont l'offre ou la date n'est pas lisible n'est pas effacée par cette tâche. Effacées à la suppression du compte du candidat, chez la société comme chez ShieldOne. **Trace d'envoi des e-mails** : R10 ②. Compteurs par compte : R4 ② | ### Note relative à R9 — pipeline commercial **Position de ShieldOne : responsable du traitement.** C'est son propre démarchage, mené pour son propre compte. C'est une exception à la position « éditeur et sous-traitant » que ShieldOne tient pour les données des entreprises clientes, comme l'espace personnel (R12, R13) et la place de marché — laquelle est gelée et sans objet. **Aucune purge, et le motif est le contact lui-même.** Le produit a d'abord appliqué une durée de deux ans d'inactivité. Elle a été **retirée le 13 août 2026** : une fiche purgée emporte, avec les coordonnées, la **raison de ne pas rappeler**. Les coordonnées professionnelles se retrouvent en une recherche ; le refus opposé en 2026, non. Purger revenait donc à faire **réapparaître** la personne démarchée dans une prochaine campagne, au lieu de la protéger. La conservation sert ici l'intérêt de la personne concernée autant que celui de ShieldOne. **Ce que ce traitement ne contient pas** : aucune donnée sensible au sens de l'art. 5 let. c LPD, aucun profilage, aucune décision automatisée, aucune donnée collectée auprès d'un tiers autre que les sources professionnelles publiques (site de l'entreprise, registre du commerce, réseau professionnel). **Droits de la personne concernée.** Toute personne figurant à ce traitement peut demander l'accès à ses données, leur rectification, leur effacement, et **s'opposer au démarchage**. La demande se fait à l'adresse contact@shieldone.ch. **Comment l'effacement est exécuté, et ce qu'il laisse subsister.** Depuis le 14 août 2026, l'interface d'administration comporte une fonction d'effacement, exécutée fiche par fiche sur demande. Elle détruit **le nom, la fonction, l'adresse électronique et le numéro de téléphone du contact, le motif de refus, ainsi que l'intégralité des comptes rendus d'échanges** — sans corbeille et sans restauration possible. Restent inscrits la **raison sociale**, le **canton** et la mention **« ne plus démarcher »**. Ce choix est délibéré, et il sert la personne concernée : depuis la révision de la loi, seules les personnes physiques sont protégées (art. 5 let. a LPD), et une raison sociale n'est pas une donnée personnelle. Supprimer la fiche entière ferait perdre, avec les coordonnées, la **raison de ne pas rappeler** — l'entreprise réapparaîtrait dans la campagne suivante, exactement comme après une purge. La mention conservée est ce qui rend l'opposition durable. **Cas particulier de la raison individuelle** : lorsque la raison sociale est le nom d'une personne physique, elle est effacée elle aussi, sur indication expresse au moment de la demande. **Ce qui est consigné de l'opération** : sa date, son auteur, le motif écrit de la demande et le nombre d'échanges supprimés. **Aucune des données effacées n'est recopiée dans cette trace** — l'y consigner reviendrait à conserver, dans un journal, ce que l'effacement vient de détruire. ### Note relative à R10 — qui lit ces trois journaux, et ce que le premier n'attrape pas **Aucun de ces trois journaux n'est lisible depuis l'application par une entreprise cliente, un responsable ou un collègue.** Les trois collections sont **fermées en lecture** au niveau de la base de données, y compris à l'administrateur. - L'**historique de connexion** n'est rendu qu'à **son propre titulaire**, par une fonction serveur dédiée, dans son écran « Sécurité du compte ». Ni l'employeur, ni la hiérarchie, ni l'administrateur de ShieldOne n'y accèdent. Le motif est direct : une collection lisible serait aussi une collection interrogeable par qui a dérobé un accès, et lui dirait quels appareils passent pour connus. - Les journaux ② et ③ ne sont rendus qu'à l'**administrateur de ShieldOne**. Le journal des e-mails est fermé pour une raison particulière : consigner qu'un message de réinitialisation a été envoyé à une adresse revient à enregistrer **qu'un compte existe** pour cette adresse. > **Ce que l'historique de connexion n'attrape pas.** Une entrée est écrite par l'application après une authentification réussie. Une connexion menée **hors de l'application** n'écrit donc aucune entrée. L'historique n'est **pas exhaustif**, et il n'est pas présenté comme tel : l'écran compare l'historique déclaré à l'horodatage de dernière connexion tenu par le service d'authentification, de sorte qu'une connexion non déclarée devienne **visible** plutôt qu'absente. ### Note relative à R17 et R18 — les verrous, et les journaux de la plateforme La collecte, la relance et chacune des suppressions automatiques de R17 et R18 sont protégées par **deux verrous** : l'un dans le code, l'autre dans la base de données. Tant que le second n'est pas ouvert, rien n'est collecté ni envoyé. **Aucune adresse d'inscription n'est enregistrée tant que son effacement automatique n'est pas en service**, et aucune durée n'est annoncée ici sans la suppression qui l'applique. Comme pour toute requête adressée à un site web, les journaux techniques de la plateforme d'hébergement (Google Cloud) gardent, pour l'ensemble du trafic, l'adresse IP et les données techniques du navigateur, **30 jours** (réglage de la plateforme relevé le 26 septembre 2026). ShieldOne ne les exploite pas pour la mesure et ne les recoupe pas avec elle. ### Note relative à R21 et R22 — ShieldOne Training **L'effacement.** La tâche de nuit qui applique l'effacement décrit à R22 est construite et s'exécute chaque nuit ; elle n'écrit que lorsque son verrou de donnée propre est ouvert, ce que ShieldOne fait avant le premier terme possible, le 9 novembre 2026. Jusqu'à son activation, aucune copie n'est effacée automatiquement, et aucune ne peut avoir atteint son terme avant le 9 novembre 2026 : aucune durée n'est annoncée ici sans la tâche qui l'applique. **Ce qu'est l'effacement chez l'organisme.** La tâche de nuit **vide** la copie des prénom, nom et adresse e-mail que l'organisme voyait ; l'organisme voit alors « Identité effacée ». L'inscription elle-même reste chez ShieldOne, rattachée à l'identifiant du compte de l'agent, qui la retrouve dans son espace : du point de vue de ShieldOne, c'est une **pseudonymisation**, non une suppression. L'identifiant technique de l'inscription, que voit l'organisme, est propre à un cours et à un agent : il ne permet pas, à lui seul, de rapprocher les inscriptions d'un même agent à des cours différents, chez le même organisme ou chez deux organismes. Il est calculé **sans valeur secrète**, à partir de l'identifiant du compte, qui n'est jamais rendu à l'organisme. Ce que l'organisme a enregistré de son côté avant l'effacement relève de lui. **Suppression du compte.** À la date de la présente version, la suppression d'un compte personnel **n'annule ni n'efface** les demandes et inscriptions ShieldOne Training, et ne retire pas l'identité de l'agent de l'espace de l'organisme ; l'adresse e-mail copiée dans une inscription continue de recevoir les avis qui s'y rapportent (annulation du cours, suspension de l'organisme, participation). Seuls sont effacés l'état de l'acceptation des conditions, porté par le profil, et l'événement de mesure d'une demande (R18). Le sort de ces données à la suppression du compte reste à arrêter. **Remboursement non reçu.** L'agent qui n'a pas été remboursé d'un cours annulé écrit à contact@shieldone.ch (*Conditions de ShieldOne Training*, article 6.6). Ce message est traité comme tout message reçu à cette adresse ; rien n'est enregistré dans l'inscription. **Ce qui n'est pas partagé.** Aucune donnée de ShieldOne Training n'est lue par ShieldOne Services ni par le logiciel professionnel de ShieldOne. Aucune entreprise cliente n'y a accès. ### Note relative à R23 et R24 — profil pro et ShieldOne Jobs **Ce que voit une société.** Par défaut, **rien** : le profil est masqué pour toutes les sociétés. La visibilité s'écrit société par société et rubrique par rubrique, sous le contrôle du seul titulaire ; à la date de la présente version, l'application ne propose pas encore ce geste, de sorte qu'une société ne reçoit, avec une candidature, que le prénom, le nom et le message. Elle ne lit un profil que par une candidature en cours, et ne voit plus rien dès qu'elle est close (embauche, refus, retrait, offre terminée) ou que l'espace personnel du candidat est fermé. **Ce que ShieldOne lit.** ShieldOne ne lit pas les profils pour trier, classer ou recommander ; un administrateur de ShieldOne habilité, pour un profil visé et après une confirmation propre à ce geste, peut consulter un profil, hors CV, pour vérifier une valeur. La vérification porte sur une valeur précise et tombe si la valeur change. Aucune pièce justificative n'est conservée dans l'application. **Lectures par les sociétés.** Chaque lecture d'une candidature par une société est tracée dans son espace, sans la valeur lue ni l'identifiant du candidat. **Effacement des candidatures.** La tâche de nuit qui l'applique (R24) est construite ; elle n'écrit que lorsque son verrou de donnée propre est ouvert, ce que ShieldOne fait avant le premier terme possible, le 10 avril 2027. **Restitution à la société.** À la fin de son contrat, la société peut obtenir la restitution de ses données : elle y retrouve les candidatures encore conservées, closes comprises, avec l'identifiant du compte du candidat, l'offre, l'état, les dates et le message, sans le profil pro. **Suppression du compte.** Elle efface le profil, le CV et les candidatures, y compris chez les sociétés, avec les traces de lecture ; en cas d'échec d'une partie, la reprise est quotidienne. Les candidatures sont rendues par l'écran « Mes données » ; le profil pro et le CV ne le sont pas encore : ils sont remis sur demande écrite (note relative à R12). ### Note relative à R15 et R16 — annonce des demandes par e-mail et mesure du quota d'envoi *(Ajoutée le 3 octobre 2026.)* À la publication d'une demande par ShieldOne, une fonction serveur l'annonce par e-mail à chaque société qui la voit dans l'application (mêmes conditions : statut de la société, autorisation cantonale, état de Pro, conditions acceptées, compte d'accès cohérent, autorisation de port d'armes pour une mission armée), sauf réglage contraire de la société (R16). Le contenu est construit par **liste fermée** (R15). Selon le réglage, l'e-mail part à la publication ou dans un récapitulatif quotidien de 7 h (heure de Genève) ; au-delà de **dix annonces dans l'heure** pour une même société, les suivantes sont regroupées en un seul e-mail l'heure suivante. Un envoi en échec est retenté une fois, au récapitulatif suivant, puis abandonné et compté dans l'e-mail suivant ; un doublon est possible lorsque Brevo a accepté un e-mail dont la réponse ne nous est pas parvenue. **Mesure du quota d'envoi.** Le quota d'envoi de Brevo est partagé avec les autres e-mails du Service, dont les codes de vérification et la réinitialisation du mot de passe. Toutes les dix minutes, une tâche lit, en lecture seule, les crédits restants du plan d'envoi au compte Brevo de ShieldOne et le nombre d'e-mails soumis sur la période, issu des statistiques agrégées de Brevo. Elle n'enregistre que des **nombres** — consommé, restant, taux —, le type de plan, le début de la période, la date de la mesure et son verdict, dans un document de la base fermé à tout accès depuis l'application et remplacé à chaque mesure. La réponse du compte Brevo porte aussi l'identité et les coordonnées du titulaire du compte de ShieldOne : elles ne sont ni exploitées ni enregistrées. Au-delà de **80 %** de consommation, ou si la mesure manque, est illisible ou date de plus de 30 minutes, les annonces qui devaient partir à la publication passent au récapitulatif quotidien, sans modifier le réglage de la société, et une alerte est inscrite pour l'administration de ShieldOne, au plus une par jour et par motif ; elle ne porte que le motif, le taux et les crédits restants, ou la cause de l'échec de la mesure : **aucune donnée personnelle**. ### Note relative à R12 — droit d'accès et remise des données (« Mes données ») Le titulaire d'un compte personnel exerce son droit d'accès et son droit à la remise de ses données (art. 25 et 28 LPD) **par écrit, à contact@shieldone.ch**. L'entrée « Accéder à mes données » de l'application est **retirée depuis le 25 septembre 2026** ; la fonction serveur qui composait le dossier décrit ci-dessous est conservée, mais n'est plus proposée dans l'application. - **Ce que le dossier contient** : les données du compte d'accès ; le profil, à l'exception des jetons de notification ; l'historique de connexion ; l'état de la validation en deux étapes (activée ou non, et ses dates), **jamais le secret** qui la protège. Le dossier nomme le responsable du traitement, ShieldOne. - **ShieldOne Training (R22)** : le dossier comprend en outre les inscriptions du titulaire — identifiants du cours et de l'organisme, état et son historique, dates, copie de ses prénom, nom et adresse e-mail transmise à l'organisme (ou la date de son effacement), prix retenu à l'acceptation, mention « certificat vérifié » et son intitulé, date de validation de la participation et, le cas échéant, date d'un signalement de remboursement non reçu — ainsi que l'état de son acceptation des conditions de ShieldOne Training. Il ne comprend ni l'identifiant de compte de la personne de l'organisme qui a validé sa participation, qui est une donnée d'un tiers, ni la date d'examen interne de l'effacement. - **Profil pro (R23) et ShieldOne Jobs (R24)** : le dossier remis sur demande écrite comprend en outre le profil pro (chaque rubrique avec sa valeur, son niveau et les sociétés à qui elle est montrée), le CV et les candidatures (société, offre, état, dates, déclaration d'avoir 18 ans, message). Les candidatures sont aussi rendues par l'écran « Mes données » ; le profil pro et le CV ne le sont pas encore, ils sont remis sur demande écrite. - **Ce que le dossier ne contient pas, et pourquoi** : le journal des événements de sécurité, les alertes qui en dérivent et les compteurs de R4 en sont exclus à dessein. Les remettre livrerait le détail de la détection — seuils franchis, règles déclenchées, volumes mesurés — à qui la déclenche, ce qui indiquerait comment l'éviter. Cette exclusion est inscrite aux points en suspens. N'y figurent pas non plus l'historique des acceptations (le profil n'en porte que l'état en vigueur), les traces d'envoi d'e-mails ni les fiches techniques internes : le dossier le dit, et la personne les obtient sur demande écrite à contact@shieldone.ch. - **Rien n'est conservé au titre de la demande** : le dossier est composé à la demande et rendu directement à la personne. Aucune copie n'est gardée, et la demande elle-même n'est pas consignée : tracer l'exercice d'un droit d'accès reviendrait à le surveiller. Seuls les compteurs par compte de R4 ② la comptent, comme tout autre appel ; un dépassement du plafond est inscrit au journal des événements de sécurité (une fois par minute), comme pour toute autre fonction. ### Note relative à R8 — données de prospect Ce traitement est inscrit au registre le 20 juillet 2026. Il était jusque-là absent, alors qu'il était, **à cette date**, **le seul traitement de données personnelles réelles effectivement en cours** : aucune entreprise cliente n'exploitait alors le Service, et les traitements S1 à S9 de la partie B ne portaient, en base, que sur des jeux de test appartenant à ShieldOne. Ce que le traitement recouvre exactement, constaté en base le 20 juillet 2026 : - Les données sont **celles que la personne a fournies elle-même** en créant son compte. Aucune donnée n'a été collectée auprès d'un tiers, et aucune n'a été enrichie. - **Aucune donnée de travailleur, aucune donnée de tiers, aucune donnée d'exploitation** n'est rattachée à ce compte : les collections correspondantes sont vides. - Les seuls documents générés depuis l'inscription le sont **par le serveur** (rapport d'activité périodique automatique), non par un usage du Service. **Aucune durée de conservation n'est annoncée**, conformément à la règle générale du présent registre : aucune purge n'est codée, donc aucune durée n'est inscrite. Une durée ne figurera ici que lorsqu'un mécanisme l'exécutera. > **Point à ne pas escamoter.** La personne concernée s'est inscrite **en juin 2026 et n'avait reçu, au 20 juillet 2026, aucune communication depuis**. Conserver ses coordonnées est défendable au titre de la démarche précontractuelle ; les conserver **indéfiniment et en silence** ne le serait pas. Le recontact au lancement n'est donc pas seulement un acte commercial : c'est ce qui donne sa réalité à la finalité invoquée. À défaut de recontact, la suppression s'impose dans un délai raisonnable. **Ce point appelle une décision, et il est inscrit aux points en suspens ci-dessous.** **Note relative à R6** : ce traitement est **en service**. À sa première connexion, puis à chaque nouvelle version de ces documents, l'application ne laisse l'utilisateur poursuivre qu'après qu'il a accepté les conditions d'utilisation et déclaré avoir pris connaissance de la politique de confidentialité (les comptes internes de test et la société de démonstration en sont dispensés) ; l'acceptation est enregistrée par le serveur, qui fixe lui-même la date et l'heure, la version et l'empreinte des documents — aucune de ces valeurs n'est fournie par le navigateur. L'**état courant** est porté par le compte et remplacé à chaque nouvelle acceptation ; il est supprimé avec le profil du compte. L'**historique** est tenu à part : chaque acceptation d'une version nouvelle y ajoute une entrée, aucune entrée n'est modifiée ni supprimée, et il n'est lisible ni modifiable depuis l'application par personne. Selon le même principe, l'**acceptation des conditions générales de vente et de l'annexe de sous-traitance** par un responsable de l'entreprise cliente (propriétaire ou manager, jamais un agent) est enregistrée une fois par entreprise et par version : identifiant, nom tel qu'il figure au compte (à défaut, la partie de l'adresse e-mail précédant l'arobase ; ce nom-là n'est jamais saisi au moment de l'acceptation), rôle, entreprise, version et empreinte des deux documents, date et heure du serveur ; depuis le 28 septembre 2026, elle porte en outre, à côté de ce nom, le nom et la fonction déclarés par la personne qui accepte et sa déclaration d'habilitation, et donne lieu à une pièce de preuve : voir **R1bis**. Selon le même principe encore, l'**attestation de lecture de la charte d'information des collaborateurs** est enregistrée pour chaque agent — il atteste l'avoir lue, il n'accepte rien —, à sa première connexion puis à chaque nouvelle version de la charte : identifiant, rôle et entreprise tels qu'ils figurent au compte, version et empreinte de la charte, date et heure du serveur. L'état courant est porté par le compte et supprimé avec son profil ; l'historique est tenu à part, chaque attestation d'une version nouvelle y ajoutant une entrée, et n'est lisible ni modifiable depuis l'application par personne. **Aucune durée n'est appliquée** à ces trois historiques : ils sont conservés sans limite et ne sont effacés ni par la suppression d'un compte ni par celle d'une entreprise cliente, parce qu'ils constituent la preuve de l'acceptation ou de l'attestation. ### Note sur la localisation des services Google — vaut pour les parties A et B La mention « Google Firebase » portée aux colonnes « destinataires » du présent registre recouvre **plusieurs services dont la localisation n'est pas la même**. La distinction est faite ici plutôt que masquée derrière une formule unique : - **Fonctions serveur** : exécution à **Zurich (`europe-west6`)**, établi par la configuration du Service. - **Base de données et stockage de fichiers** : l'emplacement est un **réglage de la console du fournisseur**, non du code. Il a été **relevé en région de Zurich (`europe-west6`) le 18 septembre 2026**, de même que celui de l'espace de sauvegarde des fichiers. - **Authentification**, **acheminement des notifications** et **service des pages du site et de l'application** : ces services **ne se configurent pas par région**. Ils **ne sont pas couverts par l'hébergement suisse**, quelle que soit la localisation de la base de données. Voir les traitements R3, R3ter et R7quater. - **Protection anti-robots (reCAPTCHA / App Check)** et **vérification du numéro par SMS** : **États-Unis**. Voir les traitements R3 et R3bis. Les **données principales** du Service sont donc en Suisse, région de Zurich. **Un stockage au repos en Suisse n'emporte pas pour autant que l'ensemble des traitements demeure en Suisse.** Cette précision vaut pour toutes les lignes des parties A et B qui mentionnent Google Firebase. ## B. Traitements pour lesquels ShieldOne est SOUS-TRAITANT (pour le compte des entreprises clientes) | # | Traitement | Personnes concernées | Catégories de données | Finalité | Destinataires / sous-traitants ultérieurs | Durée de conservation | |---|---|---|---|---|---|---| | S1 | Gestion des agents et des comptes professionnels | Agents, managers, clients du Client | Identité professionnelle, badge, équipe | Organisation opérationnelle | Google Firebase | Durée du contrat, puis suppression à la clôture du compte — **aucune purge automatique** (voir note ci-dessous) | | S2 | Rapports d'intervention | Agents, tiers concernés | Titre, lieu, description, photo, véhicule/personne/n° de pièce d'identité/n° membre | Suivi des incidents | Google Firebase | Durée du contrat, puis suppression à la clôture du compte — **aucune purge automatique** | | S3 | Missions et points de contrôle | Agents | Validation de points, horodatage, position | Suivi des missions | Google Firebase | Durée du contrat, puis suppression à la clôture du compte — **aucune purge automatique** | | S4 | Position des agents en service | Agents | Position GPS en temps réel | Supervision pendant le service | Google Firebase | **Temps réel uniquement, aucun historique** — une seule position courante par agent, écrasée à chaque mise à jour et effacée à la fin du service | | S5 | Ressources humaines et préparation de la paie | Agents | Pointages, heures, ventilation des heures, taux, éléments de préparation de la paie | Gestion RH et préparation de la paie | Google Firebase | Durée du contrat, puis suppression à la clôture du compte — **aucune purge automatique** (le Client archive ses obligations légales) | | S6 | Registres (clés, matériel, véhicules connus) | Agents, tiers | Mouvements, attributions, plaques, identifiants | Suivi opérationnel | Google Firebase | Durée du contrat, puis suppression à la clôture du compte — **aucune purge automatique** | | S7 | Lecture de plaques (ALPR) sur sites privés | Conducteurs concernés | Images (en mémoire, non conservées), n° de plaque (texte), position, horodatage, agent auteur du scan | Contrôle d'accès / parkings | Plate Recognizer — moteur **auto-hébergé par ShieldOne à Zurich** ; **aucune image ni plaque ne lui est transmise**, l'appel restant confiné au réseau privé. Échanges de vérification de licence du logiciel : **[À VÉRIFIER]** auprès du fournisseur. Google Firebase (enregistrement des lectures) | Images non conservées. **Les scans de plaques sont conservés sans limite de durée** : chaque lecture crée un enregistrement distinct, indépendant de tout élément rattaché, et aucune purge n'est implémentée (voir note ci-dessous) | | S8 | Journal d'audit | Utilisateurs professionnels | Actions horodatées (immuables). **Aucun nom en clair n'y est consigné** : seul un identifiant technique est enregistré | Traçabilité / sécurité | Google Firebase | Durée du contrat, puis suppression à la clôture du compte — **aucune purge automatique**. Les entrées sont **immuables** : elles ne peuvent être ni modifiées ni supprimées individuellement | | S9 | **Listes de personnes établies par l'entreprise cliente** — en service depuis le 19 juillet 2026 | Personnes inscrites par le Client dans ses listes (par ex. employés d'un site, personnes attendues à un événement, prestataires) | Identité, le cas échéant numéro de pièce d'identité, catégorie **définie par le Client**, commentaire libre, et **photo de visage uniquement si le Client a activé ce réglage** | Gestion des accès et de l'accueil sur les sites dont le Client a la charge. La justification du traitement relève du Client | Google Firebase | **Aucune durée n'est fixée par défaut.** Les fiches sont conservées tant que le Client ne les supprime pas, et jusqu'à la clôture de son compte. Le Client peut fixer une durée pour cette famille de données, appliquée alors par la tâche nocturne — la photo étant supprimée avec la fiche (voir la note ci-dessous) | | S10 | **Motifs d'absence et d'indisponibilité pour raison de santé** — en service depuis le 31 juillet 2026 | Agents du Client | Motif d'absence ou d'indisponibilité **saisi en texte libre par le manager**, identifiant technique de l'agent concerné, horodatage, identifiant technique de l'auteur de la saisie. Ces données sont susceptibles de constituer des **données sensibles** au sens de l'art. 5 let. c ch. 2 nLPD (données sur la santé) | Justifier une absence et organiser le remplacement | Google Firebase | **Durée configurée par l'entreprise cliente ; à défaut de choix, deux (2) ans.** Purge exécutée mensuellement par une tâche planifiée. L'entreprise peut choisir 1, 2, 5 ou 10 ans, ou « jamais ». Voir la note S10 ci-dessous | ### Note sur le traitement S10 — motifs de santé Ce traitement est **en service depuis le 31 juillet 2026**. Les garanties décrites ci-dessous sont celles que le code applique effectivement. - **Cloisonnement.** Les motifs ne sont **pas** enregistrés avec l'absence elle-même : ils vivent dans un **compartiment séparé**, dont la lecture est réservée aux comptes portant l'attribut « Santé », au propriétaire de l'entreprise et à l'administrateur de ShieldOne. Un manager ordinaire voit qu'une absence a été marquée ; **il n'en voit pas le motif**. Cette séparation est appliquée **par une règle serveur**, non par l'interface. Le **journal d'audit ne consigne aucun motif**. - **Congés.** Un congé déclaré de type « santé » **ne collecte aucun motif**. Les motifs saisis sur les autres types de congés ne relèvent pas du présent traitement. - **Durée de conservation — le Client décide, ShieldOne n'impose rien.** L'entreprise cliente fixe la durée dans l'écran « Conservation des données » : **1 an, 2 ans, 5 ans, 10 ans, ou « jamais »**. **Tant qu'elle n'a pas choisi, la valeur par défaut de deux (2) ans s'applique** — c'est la seule famille de données du Service assortie d'une durée par défaut, en raison du caractère sensible des données concernées. Toute réduction de la durée est confirmée explicitement à l'écran, et **tout changement est inscrit au journal d'audit**. - **La purge est réelle et automatique.** Une tâche planifiée s'exécute **le 1er de chaque mois** et supprime les motifs dont l'horodatage dépasse la durée retenue. La suppression est **directe et définitive** : elle ne transite **pas** par la corbeille, qui est lisible de tout manager et rétablirait la divulgation que le compartiment évite. Le journal d'audit enregistre le **nombre** de motifs supprimés et la règle appliquée, **jamais leur contenu ni l'identité des personnes concernées**. - **Persistance résiduelle en sauvegarde** : comme pour toute donnée du Service, la suppression n'est matériellement complète qu'à l'expiration de la fenêtre de sauvegarde de 98 jours. ### Note sur le traitement S9 — listes de personnes Ce traitement est **en service depuis le 19 juillet 2026**. Les garanties décrites ci-dessous sont celles que le code applique effectivement, et non des intentions : - **Aucune catégorie n'est livrée par défaut.** ShieldOne ne propose aucune taxonomie : les listes et leurs libellés sont définis par l'entreprise cliente seule. La classification « Normal / VIP / Surveillé / Interdit » qui figurait dans une conception antérieure a été **retirée du produit** et n'a jamais été mise en service. - **La photo de visage est un réglage par entreprise, désactivée par défaut.** L'absence de réglage vaut **refus** (art. 7 al. 3 LPD). Tant que l'entreprise ne l'a pas explicitement activée, aucune photo ne peut être enregistrée. Ce refus par défaut est appliqué **à la fois par l'application et par une règle serveur**, la seule protection applicative étant contournable. - **L'activation et la désactivation de ce réglage sont réservées aux managers**, et **chaque bascule est inscrite au journal d'audit**. - **La création et la modification des fiches sont réservées aux managers**, tant pour les données que pour les fichiers photo. Cette restriction est appliquée **côté base de données et côté stockage de fichiers**, et a été vérifiée par test serveur. - **Le journal d'audit ne consigne aucun nom en clair** : il n'enregistre qu'un identifiant technique. **Aucune durée de conservation n'est annoncée pour ce traitement**, parce qu'aucune purge automatique n'est implémentée. Il appartient à l'entreprise cliente, responsable du traitement, de supprimer les fiches devenues inutiles et d'apprécier la proportionnalité des données qu'elle inscrit. Une durée ne sera inscrite au présent registre que lorsqu'un mécanisme l'exécutera effectivement. ### Note sur les durées de conservation — correction de la version 1.1 Les versions antérieures du présent registre annonçaient une durée de « **contrat + 90 jours** » pour les traitements R1 et S1 à S8, ainsi qu'une conservation des numéros de plaque limitée à « la durée de vie de l'élément rattaché » (S7). **Ces durées n'étaient pas exécutées par le produit.** Vérification faite sur le code à la date de la présente version : > **MISE À JOUR DU 31.07.2026.** Les quatre constats ci-dessous dataient de la version 1.1 > (19.07.2026). Trois d'entre eux sont devenus **faux** depuis, les mécanismes correspondants > ayant été développés et déployés. Ils sont réécrits ici sur la base d'une vérification du code > et de l'état de déploiement réel des tâches planifiées. - **Des tâches planifiées de purge existent désormais et s'exécutent en production** : (i) une tâche **nocturne** qui applique, pour chaque famille de données, la durée que **l'entreprise cliente** a configurée — **aucune durée n'est fixée par défaut**, si bien qu'une entreprise qui n'a rien configuré ne voit rien purgé ; (ii) le **vidage de la corbeille** à 7 jours ; (iii) la **suppression des PDF d'export** à 7 jours ; (iv) une tâche **mensuelle** qui purge les **motifs d'absence pour raison de santé** (traitement **S10**) selon la durée que l'entreprise a configurée, **avec une valeur par défaut de deux (2) ans** — seule durée par défaut du Service, justifiée par le caractère sensible de ces données. - **Aucun compte à rebours de 90 jours n'est déclenché par la fin d'un contrat.** Ce constat reste **exact** : aucun champ de date de fin, aucun mécanisme de décompte, aucune suppression différée n'existent. - **La suppression d'une entreprise cliente est outillée et s'effectue en cascade** (données Firestore et comptes d'accès), sur **déclenchement manuel** d'un administrateur ShieldOne et après export intégral préalable. **Exception délibérée** : les **fichiers** déposés dans le stockage (photos de rapports, documents) ne sont pas supprimés par cette opération et disparaissent avec l'expiration de la fenêtre de sauvegarde de 98 jours. - **Les scans de plaques (S7) ne sont pas purgés par défaut** : chaque lecture crée un enregistrement autonome, horodaté et localisé, indépendant de la durée de vie d'un rapport, d'une fiche de parking ou d'une liste de surveillance. Ils sont purgés **si et seulement si** l'entreprise cliente fixe une durée pour cette famille. **Aucune image n'y est jamais enregistrée** : les règles d'accès à la base refusent tout champ hors de la liste des champs texte attendus. **Le registre annonce désormais ce que le produit fait, et non ce qu'il devrait faire.** Annoncer une durée de conservation qui n'est pas appliquée crée un écart entre le document publié et le comportement réel du traitement ; cet écart est précisément ce que l'on cherche ici à supprimer. Les durées ci-dessus seront resserrées lorsque, et seulement lorsque, un mécanisme de purge aura été mis en service — le registre sera alors mis à jour avec la durée effectivement exécutée. **Réserve de méthode** : l'articulation exacte entre un registre des traitements inexact au sens de l'art. 12 LPD et les dispositions pénales de la LPD n'est pas tenue pour acquise et doit être posée à l'avocat. La correction est faite indépendamment de cette question, parce que l'écart entre le document et le code est établi et qu'il est corrigible sans délai. **Persistance résiduelle en sauvegarde** : indépendamment de ce qui précède, une donnée supprimée en production demeure présente dans les sauvegardes techniques **pendant au maximum 98 jours** (voir `10-mesures-securite.md`, § 1.6). Aucune suppression n'est matériellement complète avant l'expiration de la dernière sauvegarde contenant la donnée. ## C. Mesures de sécurité (transversales) Cloisonnement multi-locataire strict ; autorisations par jetons sécurisés ; chiffrement en transit et au repos (Google Cloud) ; contrôle d'intégrité applicatif (App Check) ; accès restreint ; journal d'audit immuable ; notification de violation au responsable concerné sans délai et au plus tard 48 h. Le détail des mesures techniques et organisationnelles figure dans le document `10-mesures-securite.md`. ## D. Traitements clos Cette partie conserve la trace des traitements qui ont été **arrêtés**. Elle n'est pas supprimée du registre : elle constitue la **preuve qu'une clôture a été conduite** et documente le sort réservé aux données. Effacer ces lignes ferait disparaître cette preuve. | # | Traitement | Période d'activité | Motif de la clôture | Sous-traitants concernés | Sort des données | Date du constat | |---|---|---|---|---|---|---| | **CANAL-clos** | **Canal de discussion d'équipe** (« Canal Alpha ») — messagerie interne entre agents et manager d'une même entreprise | Mise en service **non datée** (antérieure au 19.07.2026) → **20 juillet 2026** | **Démantèlement décidé par ShieldOne.** Le canal n'avait jamais fait l'objet d'un audit et ne figurait **pas au présent registre** — c'est un **manquement, énoncé ici plutôt que passé sous silence** : un traitement a fonctionné sans être inscrit. Il était par ailleurs « masqué » par un simple drapeau d'interface, alors que la collection restait **ouverte en lecture et en écriture à tout le personnel** de l'entreprise | Google Firebase (hébergement) ; Google Firebase Cloud Messaging (notification de nouveau message, **sans le contenu**) | **8 messages subsistent**, tous dans **une seule société, de test, appartenant à ShieldOne** — aucune donnée de client réel. Contenu : texte libre saisi par l'auteur, identifiant de l'auteur, horodatage. Le code est **retiré**, l'accès **refermé en lecture et en écriture** ; les messages **ne sont pas supprimés**, leur sort relève d'une décision expresse. **Aucune durée de conservation n'est annoncée**, aucune purge n'étant codée | 20 juillet 2026 | | R1‑clos | Comptes citoyens | 11 juin 2026 – 19 juillet 2026 | Fermeture du module citoyen ; recentrage sur une offre B2B web uniquement | Google Firebase, Google reCAPTCHA, Firebase Phone Auth | **Traitement clos le 19 juillet 2026.** Inventaire des comptes **clos, résultat nul** : aucun compte citoyen n'existe dans la base, donc **aucune personne concernée à informer**. La **purge des collections reste planifiée et non exécutée** à la date de la présente version. | 19 juillet 2026 | | R2‑clos | Signalements communautaires | 11 juin 2026 – 19 juillet 2026 | Fermeture du module citoyen | Google Firebase, Mapbox | **Traitement clos le 19 juillet 2026.** Inventaire des comptes **clos, résultat nul** : aucun compte citoyen n'existe dans la base, donc **aucune personne concernée à informer**. La **purge des collections reste planifiée et non exécutée** à la date de la présente version. | 19 juillet 2026 | | R3‑clos | Alerte SOS | 11 juin 2026 – 19 juillet 2026 | Fermeture du module citoyen, envoi de SMS inclus | Google Firebase, ASPSMS | **Traitement clos le 19 juillet 2026.** Inventaire des comptes **clos, résultat nul** : aucun compte citoyen n'existe dans la base, donc **aucune personne concernée à informer**. La **purge des collections reste planifiée et non exécutée** à la date de la présente version. | 19 juillet 2026 | | R4‑clos | SafeWalk | 11 juin 2026 – 19 juillet 2026 | Fermeture du module citoyen | Google Firebase | **Traitement clos le 19 juillet 2026.** Inventaire des comptes **clos, résultat nul** : aucun compte citoyen n'existe dans la base, donc **aucune personne concernée à informer**. La **purge des collections reste planifiée et non exécutée** à la date de la présente version. | 19 juillet 2026 | | R5‑clos | Notifications de quartier / push citoyen | 11 juin 2026 – 19 juillet 2026 | Fermeture du module citoyen | Google Firebase Messaging | **Traitement clos le 19 juillet 2026.** Inventaire des comptes **clos, résultat nul** : aucun compte citoyen n'existe dans la base, donc **aucune personne concernée à informer**. La **purge des collections reste planifiée et non exécutée** à la date de la présente version. | 19 juillet 2026 | | R6‑clos | Abonnement « Citoyen Premium » | 11 juin 2026 – 19 juillet 2026 | Fermeture de l'offre citoyenne ; paiement en ligne fermé par **un verrou d'interface et un verrou serveur**, ce dernier refusant toute demande quel que soit l'état du premier. **Aucune donnée n'est transmise à Stripe.** **MISE À JOUR DU 01.08.2026 : le module de paiement en ligne a été ENTIÈREMENT SUPPRIMÉ** — points d'entrée, point de réception des messages du prestataire, secrets et dépendance logicielle. L'état résiduel décrit dans la version précédente (un point de réception encore déployé, neutralisé par un verrou serveur) **n'existe plus** : il n'y a plus rien à neutraliser | Stripe (États-Unis) | **Traitement clos le 19 juillet 2026.** Inventaire des comptes **clos, résultat nul** : aucun compte citoyen n'existe dans la base, donc **aucune personne concernée à informer**. La **purge des collections reste planifiée et non exécutée** à la date de la présente version. Les données détenues par Stripe restent soumises aux obligations légales de conservation de ce prestataire. | 19 juillet 2026 | | ST‑clos | Envoi de SMS (alertes SOS et journaux d'envoi associés) | 11 juin 2026 – 19 juillet 2026 | Fermeture du module citoyen ; **ASPSMS n'est plus appelé par le code — aucune occurrence subsistante, vérifiée** | ASPSMS (Suisse) | **Traitement clos le 19 juillet 2026.** Inventaire des comptes **clos, résultat nul** : aucun compte citoyen n'existe dans la base, donc **aucune personne concernée à informer**. La **purge des collections reste planifiée et non exécutée** à la date de la présente version. Résiliation du compte prestataire à confirmer. | 19 juillet 2026 | | MOD‑clos | Module citoyen (ensemble fonctionnel) | 11 juin 2026 – 19 juillet 2026 | Décision de recentrage : plateforme B2B pure, web uniquement | Google Firebase, Mapbox, Stripe, ASPSMS, Firebase Phone Auth | **Traitement clos le 19 juillet 2026.** Inventaire des comptes **clos, résultat nul** : aucun compte citoyen n'existe dans la base, donc **aucune personne concernée à informer**. La **purge des collections reste planifiée et non exécutée** à la date de la présente version. | 19 juillet 2026 | | PERS‑abandonné | **Registre de « personnes connues »** — conception antérieure : fiches d'individus avec **photo de visage** et catégorie livrée par défaut avec les valeurs « Normal », « VIP », « Surveillé », « Interdit » | **Jamais mis en production — aucune période d'activité** | **Conception abandonnée avant toute mise en service.** Motifs : qualification incertaine de la photo de visage au regard de l'art. 5 let. c ch. 4 LPD ; risque de basculement vers le ch. 5 par le champ commentaire libre ; absence de base de justification documentée par fiche (art. 30-31 LPD) ; absence de mécanisme d'information des personnes concernées (art. 19 LPD) ; **taxonomie « Surveillé / Interdit » livrée par défaut**, facteur de co-détermination au sens de l'art. 5 let. j LPD | Google Firebase (aucune donnée déposée) | **Aucune donnée à purger. Aucune personne à informer.** Cette conception **n'a jamais été mise en production** : aucune fiche n'a été créée, aucune photo de visage n'a été téléversée, aucun tiers n'a été inscrit. Elle a été **remplacée** par le traitement **S9** de la partie B, qui ne livre aucune catégorie et désactive la photo par défaut | **19 juillet 2026** | > **Ce que la ligne PERS‑abandonné recouvre exactement.** Elle décrit une conception **écartée**, > et non un module retiré du produit. Le module de listes de personnes **est en service** depuis > le 19 juillet 2026 et figure en **partie B sous la référence S9** ; c'est là qu'il faut le lire. > > La conception abandonnée s'en distingue sur les points qui motivaient précisément son abandon : > > - elle **livrait une taxonomie par défaut** — « Normal / VIP / Surveillé / Interdit » — désormais > **retirée du produit** : l'entreprise cliente définit seule ses listes et leurs libellés ; > - elle prévoyait la **photo de visage activée sans réglage préalable** ; la version en service > la **désactive par défaut**, avec une règle serveur qui rejette toute photo tant que > l'entreprise ne l'a pas explicitement activée (art. 7 al. 3 LPD) ; > - elle consignait des **identités en clair au journal d'audit** ; la version en service > n'y inscrit qu'un identifiant technique. > > **Aucune durée de conservation n'est annoncée pour le traitement S9**, faute de purge en > service. Une durée ne sera inscrite que lorsqu'un mécanisme l'exécutera — règle générale du > présent registre. **Mention transitoire — portée générale de la partie D** : les traitements ci-dessus ne sont plus alimentés et ne sont plus accessibles depuis l'application. L'**inventaire des comptes citoyens est clos** : il a été conduit le 19 juillet 2026 et a établi qu'**aucun compte citoyen n'existe** dans la base. Il n'y a donc **aucune personne concernée à informer** au titre de ces traitements. En revanche, la **purge des collections de données correspondantes reste planifiée et non exécutée** à la date de la présente version, et **leur décompte n'a pas été établi** : l'inventaire clos portait sur les comptes d'utilisateurs, non sur ces collections. Le registre sera mis à jour dès l'exécution de la purge, avec sa date effective et sa portée. **Exception expresse — PERS‑abandonné** : la mention transitoire ci-dessus **ne s'applique pas** à cette ligne. Les traitements R1‑clos à MOD‑clos et ST‑clos **ont eu lieu**. La conception écartée de registre de « personnes connues », elle, **n'a jamais tourné** : il n'y a **ni donnée résiduelle, ni purge à planifier, ni information de personne concernée à envisager**. Son abandon est une **mise à jour purement documentaire**. ## Points en suspens - **Âge minimum d'utilisation — deux volets.** **Volet professionnel** : les documents publiés retiennent **18 ans** ; ce point est soumis à validation juridique et sera confirmé ou corrigé dans une prochaine version. **Espace personnel** : **16 ans** (conditions d'utilisation de l'espace personnel, article 3.1). La personne déclare avoir atteint cet âge avant son premier accès ; la déclaration est enregistrée avec la preuve d'acceptation (R12) et n'est pas vérifiée. **ShieldOne Training (R22)** ne prévoit pas d'âge distinct, sauf pour le type de cours « Découverte du tir », réservé aux personnes de 18 ans révolus qui l'attestent sur l'honneur (attestation non enregistrée) : un titulaire d'un compte personnel de moins de 18 ans peut demander à s'inscrire aux autres types, y compris à un cours payant, et ses prénom, nom et adresse e-mail sont transmis à l'organisme ; ShieldOne ne recueille pas l'accord de son représentant légal. Le **profil pro (R23)** n'a pas d'âge distinct de celui de l'espace personnel : une personne de 16 ou 17 ans peut y déclarer une attestation d'arme ou un parcours, sans vérification de son âge. **ShieldOne Jobs (R24)** est réservé aux personnes de 18 ans révolus, par déclaration à chaque candidature, non vérifiée. - **Purge des collections des traitements clos** : l'inventaire des **comptes** est clos, avec un résultat nul. Le **décompte et la purge des collections** de données citoyennes restent à conduire. - **Conservation des publications et des signalements ShieldOne Local (R19)** : tranchée par décision du 30 septembre 2026 et appliquée à compter de la présente version — publication effacée 30 jours après sa mise en ligne ou sa soumission, décompte anonyme conservé ; signalements effacés 12 mois après leur classement ; blocage levé effacé 12 mois après sa levée. Les publications d'un auteur bloqué suivent le même terme : un blocage peut se lever depuis la liste des auteurs bloqués, sans passer par une publication. Un blocage en cours est conservé tant qu'il dure, sans durée maximale ; la proportionnalité de cette conservation est soumise à validation juridique. - **Décompte des publications effacées (R19)** : il ne porte aucun identifiant ; un nombre très faible (petite commune, une catégorie, un mois) pourrait toutefois être rapproché d'une personne. Son caractère anonyme, et la nécessité d'un seuil minimal de regroupement, sont soumis à validation juridique. - **Recherche et vérification d'adresse (R19)** : la qualité de swisstopo (destinataire, sans identifiant, du texte tapé et, à l'enregistrement d'un lieu, du libellé de l'adresse choisie, qui désigne souvent un domicile), et le passage de ces textes par un réseau de diffusion établi aux États-Unis, sont soumis à validation juridique. - **Trace des décisions de modération ShieldOne Local (R19)** : cette trace, au journal de l'administration, ne porte ni l'identifiant de l'auteur ni celui du signalant — celle d'un blocage ou de sa levée peut toutefois porter une clé calculée à partir de l'identifiant de compte de l'auteur, qui n'est pas anonyme et survit à la suppression du compte —, et **aucune durée ne lui est appliquée** — même régime que le journal des événements de sécurité (R4 ①). La décision du 30 septembre 2026 fixe à 12 mois la conservation des décisions de modération : elle est appliquée aux décisions enregistrées avec le signalement et le blocage levé (celles que porte la publication partent avec elle, à 30 jours), **pas encore à cette trace**, qui survit à leur effacement ; son effacement suivra celui du journal de l'administration, non mis en service à la date de la présente version. **Aucune durée n'est annoncée** tant qu'il ne l'est pas. - **Bases de transfert à l'étranger** : la vérification, destinataire par destinataire, des certifications ou clauses contractuelles types applicables aux transferts vers les États-Unis est **en cours et non achevée**. Elle vaut aussi pour l'espace personnel (R12, R13) : authentification, reCAPTCHA, bibliothèques et polices chargées depuis des domaines Google. - **Chargement du kit de développement Firebase depuis un domaine Google** : l'adresse IP des visiteurs est transmise à Google au démarrage de l'application (traitement R7). Le rapatriement local de ces bibliothèques n'a pas été entrepris, le risque sur la chaîne d'authentification ayant été jugé disproportionné. - **Chargement des polices de caractères depuis un domaine Google** (traitement R7bis) : point **relevé le 20 juillet 2026**, absent des versions antérieures du présent registre. Les autres bibliothèques tierces ont été rapatriées sur le domaine de ShieldOne ; les polices ne l'ont pas été. Leur rapatriement est techniquement possible et reste à arbitrer. - **Localisation des services Google sans réglage régional** : l'**authentification** (R3), l'**acheminement des notifications** (R3ter) et le **service des pages du site et de l'application** (R7quater) ne se configurent pas par région et ne sont pas couverts par l'hébergement suisse. Leur localisation effective et la base du transfert correspondante **ne sont pas établies** et doivent l'être auprès du fournisseur. - **Échanges de vérification de licence du moteur ALPR** (S7) : le confinement des images et des plaques au réseau privé de ShieldOne est établi par la configuration du Service. Ce que le logiciel du fournisseur communique de lui-même à Plate Recognizer au titre de sa licence **n'est pas établi** et doit l'être auprès du fournisseur. - **Empreinte d'adresse IP du formulaire « mot de passe oublié »** (R4, et R13 pour l'espace personnel) : elle est calculée sans valeur secrète, ce qui permet, par calcul, de retrouver l'adresse IP, et **aucune durée n'est appliquée**. Un correctif est à l'étude ; s'il est mis en œuvre, le registre et la politique de confidentialité de l'espace personnel seront mis à jour en même temps. - **Journal des événements de sécurité (R4 ①, y compris pour les comptes personnels, R13)** : aucune durée n'est appliquée ; les entrées et les alertes qui en dérivent, qui portent l'adresse e-mail, sont conservées sans limite, y compris après la suppression du compte. **Aucune durée n'est annoncée** tant qu'aucun mécanisme n'en applique une ; la décision reste à prendre. - **Journal des événements de sécurité et droit d'accès** : ce journal et les alertes qui en dérivent sont exclus du dossier remis au titre du droit d'accès (note relative à R12), pour le motif exposé dans cette note. La portée de cette exclusion est soumise à validation juridique. - **Comptes personnels inactifs (R12)** : aucune suppression n'est appliquée. Un compte inutilisé est conservé tant que la personne ne le supprime pas. - **Effacement déclenché par la suppression d'un compte personnel (R12)** : l'historique de connexion, les fiches techniques internes et le secret de validation en deux étapes sont effacés par une tâche distincte de la suppression elle-même. Un échec de cette tâche n'est pas signalé à la personne. - **Demandes reçues par le site (R9bis)** : aucune durée n'est appliquée, y compris aux demandes d'organismes de formation, validées ou non ; la décision reste à prendre. - **Portée du masquage avant envoi à Sentry** : seuls les adresses e-mail et les identifiants de compte sont masqués, et **seulement dans une partie de l'événement** — le message, le libellé des erreurs et le fil des actions précédentes. Les chemins techniques des piles d'appel et les champs ajoutés par le kit du fournisseur **ne sont pas traversés** par ce filtre. Des données personnelles figurant en texte libre dans une trace d'erreur ne sont pas couvertes. - **Absence de purge des listes de personnes (S9)** : le module est en service et aucun mécanisme n'exécute de durée de conservation. **Aucune durée n'est annoncée** tant que ce sera le cas. - **Sort du compte de prospect (R8)** : aucune durée n'est appliquée et aucune purge n'est codée. Deux branches sont ouvertes et **aucune n'est tranchée** : recontact au lancement — qui donne sa réalité à la finalité précontractuelle invoquée — ou suppression dans un délai raisonnable. **Le silence prolongé n'est pas une troisième branche** : il ne fait que reporter la décision tout en prolongeant la conservation. - **Conservation sans limite du pipeline commercial (R9)** : ce point **n'est pas en suspens, il est tranché** — aucune purge, par décision du 13 août 2026, pour le motif exposé à la note R9. La **fonction d'effacement d'une fiche** est **en service depuis le 14 août 2026** ; sa portée exacte est décrite à la note R9. - **Absence de purge automatique des données professionnelles** : aucun mécanisme n'exécute de durée de conservation sur les traitements R1 et S1 à S9. Les durées annoncées ont été corrigées en conséquence dans la présente version. La mise en service d'une purge, et la durée qu'elle appliquera, restent à décider. - **Suppression en cascade d'une entreprise cliente** : l'opération de suppression ne supprime pas l'ensemble des données rattachées. Écart technique identifié, à corriger avant de pouvoir annoncer une suppression complète à la clôture du compte. - **Conservation illimitée des scans de plaques (S7)** : aucune durée n'est appliquée. Tant qu'aucune purge n'est en service, **aucune durée ne doit être annoncée** pour ce traitement. - **Empreinte d'adresse IP du parcours d'inscription (R18)** : comme celle du formulaire « mot de passe oublié », elle est calculée sans valeur secrète et **aucune durée n'est appliquée**. **Aucune durée n'est annoncée** tant qu'aucun mécanisme n'en applique une. - **Fenêtre de sauvegarde portée à 98 jours** (constat U1 du 19.07.2026) : arbitrage délibéré en faveur de la capacité de récupération. Conséquence sur l'effectivité des demandes d'effacement, à porter à la connaissance de l'avocat. - **Annonce des demandes par e-mail (R15, R16)** : réglage par défaut des sociétés sur un e-mail à chaque demande, avec un lien de réglage dans chaque e-mail, au regard de l'art. 3 al. 1 let. o LCD ; envoi à une adresse qui peut être nominative ; copie conservée par la société hors du contrôle de ShieldOne, ce que la politique de confidentialité de l'espace personnel signale ; risque résiduel de reconnaissance d'un demandeur dans une petite commune ; couverture de l'annonce par le consentement au partage anonyme recueilli au dépôt, dont le texte ne nomme pas l'e-mail ; file d'envoi par société sans durée, bornée en nombre. Ces points sont **soumis à validation juridique**. - **ShieldOne Training — inscriptions conservées sans durée (R22)** : seule la copie de l'identité transmise à l'organisme est effacée, et seulement pour une demande refusée ou une demande ou inscription annulée. Les inscriptions acceptées, celles dont la participation a été indiquée et les demandes restées en attente, avec la copie de l'identité que voit l'organisme, ne font l'objet d'aucune suppression automatique ; les inscriptions elles-mêmes restent rattachées au compte, y compris après sa suppression. La proportionnalité de cette conservation, et la qualification de l'effacement comme pseudonymisation pour ShieldOne, sont soumises à validation juridique. - **ShieldOne Training — suppression du compte personnel (R22)** : elle n'annule ni n'efface les demandes et inscriptions, et ne retire pas l'identité de l'agent de l'espace de l'organisme. Le sort de ces données reste à arrêter. - **ShieldOne Training — organismes de formation (R21)** : aucune durée n'est appliquée et aucune fonction de suppression d'un organisme ou de son compte n'existe ; les liens de définition du mot de passe utilisés ou expirés, les cours passés et l'historique des suspensions, dont le motif est un texte libre, sont conservés sans limite. **Aucune durée n'est annoncée** tant qu'aucun mécanisme n'en applique une ; la décision reste à prendre. - **ShieldOne Training — empreinte d'adresse IP de la page de définition du mot de passe d'un organisme (R21)** : comme celle du formulaire « mot de passe oublié », elle est calculée sans valeur secrète et **aucune durée n'est appliquée**. - **ShieldOne Training — lieu de traitement par l'organisme (R22)** : ShieldOne ne contrôle pas où l'organisme traite les données qu'il reçoit ; la portée de l'engagement de l'article 10.3 des *Conditions de ShieldOne Training* est soumise à validation juridique. - **Profil pro (R23) — données sensibles et vérification** : le profil peut porter une attestation d'arme (canton, date de validité) et des informations de parcours ; leur qualification au regard de la nLPD, la base de la vérification par ShieldOne et la proportionnalité d'une conservation sans durée d'inactivité sont soumises à validation juridique. **Aucune durée n'est annoncée** au-delà de la suppression du compte. - **Profil pro (R23) — trace au journal de l'administration** : elle est conservée sans durée à ce jour ; la décision de la limiter à 12 mois n'est pas encore appliquée. **Aucune durée n'est annoncée** tant qu'aucun mécanisme n'en applique une. - **ShieldOne Jobs (R24) — candidatures** : la qualité de destinataire de la société qui reçoit une candidature (responsable de son propre traitement), la proportionnalité de la conservation à 6 mois et l'absence, à la date de la présente version, de la restitution du profil pro et du CV par l'écran « Mes données » sont soumises à validation juridique. Une candidature dont l'offre ou la date n'est pas lisible n'est pas effacée par la tâche. - **Analyse d'impact du profil pro (R23) et de ShieldOne Jobs (R24)** : ouverts le 10 octobre 2026, ils ne figurent pas encore dans l'analyse d'impact (`/legal/17-aipd-plateforme-publique.md`) ; elle les décrira dans une prochaine version. - **ShieldOne Jobs — offres des sociétés clientes** : le traitement par ShieldOne des offres publiées par les sociétés et des actes de leurs représentants dans ShieldOne Jobs n'est pas encore décrit à la partie B du présent registre ; il y sera porté. --- *ShieldOne — Sacha Frija, entreprise individuelle · Chemin Frisco 6, 1208 Genève, Suisse · Version 1.29 — 11 octobre 2026*