Politique de confidentialité — ClearlyAccess

Dernière mise à jour : 2026-08-23

---

Comment lire ce document

Ce texte s'adresse à deux personnes très différentes, et il essaie de servir les deux sans mentir à l'une pour rassurer l'autre.

• Vous êtes un visiteur — vous venez de scanner un QR code à l'entrée d'un bâtiment et vous vous demandez ce qu'il advient de votre nom et de votre pièce d'identité. Lisez le § 1, le § 4.4 (la photo de votre pièce) et le § 9 (vos droits). Le reste vous concerne moins.
• Vous êtes délégué à la protection des données d'un hôpital ou d'une organisation qui envisage ClearlyAccess. Lisez tout, et particulièrement le § 2 (qui est responsable de quoi), le § 4.7 (décision automatisée), le § 5 (registre inaltérable et droit à l'effacement), le § 8 (sous-traitants ultérieurs) et le § 15 (ce que ce produit ne fait pas encore).

Nous avons écrit ce document en partant du code, ligne par ligne, et non de ce que nous aurions aimé pouvoir promettre. Là où le produit ne tient pas ce qu'un texte commercial — ou une version antérieure de cette page — a pu laisser entendre, nous le disons : c'est le cas au § 2.1, au § 4.4, au § 4.6, au § 5.1, au § 6.4, au § 7 et au § 9.1. Là où une réponse n'est pas établie, nous écrivons qu'elle ne l'est pas au lieu d'en inventer une, et les limites connues du produit sont rassemblées à la fin, au § 15.

---

1. En bref, pour un visiteur

Quand vous vous enregistrez à l'entrée d'un bâtiment avec ClearlyAccess :

• Vous n'avez pas de compte, pas de mot de passe, pas d'adresse e-mail à donner. Vous n'en aurez jamais : le produit est construit pour que les visiteurs ne soient jamais des utilisateurs inscrits.
• Nous enregistrons votre nom, votre prénom, la société que vous déclarez, la personne que vous venez voir, le motif de votre visite, et vos heures d'entrée et de sortie.
• Si vous photographiez votre pièce d'identité, cette photo est transmise à notre serveur puis à un service de lecture automatique. Elle n'est enregistrée nulle part, mais elle quitte bien votre téléphone. Le détail exact est au § 4.4, et vous pouvez vous en passer : la saisie à la main est toujours possible.
• Le numéro de votre pièce d'identité n'est jamais conservé. Seule une empreinte irréversible en est gardée, pour vous reconnaître à votre prochaine visite sans avoir à vous redemander qui vous êtes.
• Vous pouvez consulter, télécharger et faire effacer vos données depuis votre téléphone, en trois gestes, à partir de votre badge — sans écrire à personne. Voir le § 9. Une réserve, et elle est réelle : ce chemin ne fonctionne que si vous vous êtes enregistré vous-même. Si c'est l'agent d'accueil qui l'a fait à votre place, il répond « badge inconnu » et il faut vous adresser à l'organisation — voir le § 5.7.
• L'organisation qui vous a accueilli décide combien de temps ces données sont gardées — 365 jours par défaut, et une purge automatique s'exécute chaque nuit. Le détail, y compris ce qui n'est pas effacé par cette purge, est au § 4.6.

---

2. Qui est responsable de quoi — la distinction qui commande tout le reste

Le RGPD distingue deux rôles. Le responsable du traitement décide pourquoi et comment des données sont traitées. Le sous-traitant exécute ces traitements pour le compte du responsable, en suivant ses instructions, sans décider des finalités.

ClearlyAccess occupe les deux rôles, sur des données différentes. Confondre les deux est l'erreur la plus fréquente de ce type de document, et elle a des conséquences très concrètes pour vous : elle change qui vous devez contacter et à qui vous pouvez réclamer.

2.1 Données des visiteurs de bâtiments → nous sommes sous-traitant

Quand vous vous enregistrez à l'accueil d'un hôpital, le responsable du traitement est cet hôpital, pas nous. C'est lui qui a décidé de tenir un registre de visiteurs, qui en fixe la finalité (sécurité, traçabilité, évacuation), qui choisit la base légale, qui règle la durée de conservation et qui décide si une pièce d'identité est demandée.

Nous fournissons l'outil et hébergeons les données. Nous n'exploitons le contenu des registres de nos clients pour aucune finalité qui nous soit propre : ni prospection, ni revente, ni entraînement de modèles, ni statistiques commerciales.

Une exception, et il faut la nommer ici plutôt que de la laisser au § 11.3. Les applications visiteur et accueil envoient à notre propre outil de mesure d'audience quelques événements d'étape anonymes — « tunnel ouvert », « identité franchie », « enregistré » — dont la finalité est la nôtre : savoir où les gens abandonnent le parcours. Aucun nom, aucune donnée de visite, aucune adresse de page n'y figure ; les seules propriétés envoyées sont la langue et, le cas échéant, un code de refus. Mais c'est bien un traitement décidé par nous, et non une instruction du client. Nous le déclarons plutôt que de le loger sous une phrase absolue qui serait fausse. Un client qui ne le veut pas doit pouvoir l'exiger : cette limite figure au § 15.

Ce n'est pas une déclaration d'intention : c'est la structure de la base de données qui l'impose. Chaque organisation cliente est cloisonnée au niveau du moteur PostgreSQL lui-même (voir § 10.2), et l'effacement que vous demandez chez un client ne s'applique qu'à ce client — pas parce que nous filtrons, mais parce que la base traite ces deux registres comme appartenant à deux responsables distincts (voir § 5.5). Une nuance importante, et nous la décrivons plutôt que de la taire : le référentiel de personnes, lui, est commun à tous nos clients — sans qu'aucun puisse jamais y lire ce qui relève d'un autre. Le mécanisme exact est au § 10.2, et c'est lui qui explique pourquoi l'effacement de l'empreinte de votre pièce est conditionnel (§ 5.2).

2.2 Données de nos clients et de nos prospects → nous sommes responsable

Pour les comptes des personnes qui utilisent ClearlyAccess — l'administrateur qui paramètre un bâtiment, l'agent d'accueil qui contrôle un badge — et pour les personnes qui remplissent le formulaire de démonstration sur notre site, c'est nous le responsable du traitement. C'est nous qui décidons de créer des comptes, de facturer, d'envoyer un e-mail d'invitation, de mesurer l'audience de notre site.

2.3 Ce que cela change pour vous, concrètement

Une conséquence à laquelle un DPO d'établissement doit s'attendre : en tant que sous-traitant, nous ne pouvons pas répondre à votre place aux demandes de vos visiteurs qui sortiraient du parcours automatisé décrit au § 9. Nous vous les transmettons.

---

3. Qui nous sommes

ClearlyAccess est un service de registre de visiteurs pour bâtiments, édité par :

ICLICS SRL Chemin du Beau Vallon 42, 5100 Namur, Belgique Numéro d'entreprise (BCE) : 0548.813.132 — TVA : BE 0548.813.132 RPM Liège, division Namur

Dénomination, adresse, numéro d'entreprise et ressort judiciaire relevés le 22/08/2026 sur la fiche publique de la Banque-Carrefour des Entreprises.

Contact : voir § 13.

Délégué à la protection des données

Un délégué à la protection des données (DPO, de l'anglais data protection officer) est une personne désignée pour veiller au respect du RGPD à l'intérieur d'une organisation, en toute indépendance. L'article 37 du RGPD ne l'impose que dans trois cas.

ICLICS SRL n'en a pas désigné, et ce n'est pas un oubli : c'est le résultat de l'examen de ces trois cas, que nous exposons ici pour qu'il puisse être contredit.

1. Autorité ou organisme public (art. 37.1.a) — non : ICLICS SRL est une société commerciale de droit privé. La question se pose en revanche pour beaucoup de nos clients : un hôpital public, un CPAS ou une intercommunale, eux, ont un DPO obligatoire.
2. Traitement à grande échelle de données sensibles au sens de l'article 9 — non : le produit ne demande aucune donnée de santé, le registre inaltérable ne contient aucune donnée personnelle de visiteur, et le numéro de la pièce d'identité n'est jamais conservé (§ 4.5). Une réserve honnête, qui vaut aussi pour l'organisation qui nous emploie : le champ libre « motif de la visite » est saisi par un être humain, et rien n'empêche techniquement d'y écrire quelque chose qui révèle un état de santé. Le contrat de sous-traitance l'interdit au client ; cette interdiction est juridique, elle n'est pas technique.
3. Suivi régulier et systématique de personnes à grande échelle (art. 37.1.b) — c'est le seul cas sérieux, et il faut le dire ainsi. Tenir un registre d'entrées et de sorties est un suivi régulier et systématique ; c'est même l'objet du produit. Ce qui manque aujourd'hui est la grande échelle : ClearlyAccess n'a aucun client en exploitation à la date de ce document, donc aucune personne concernée réelle. Trois des quatre conditions sont donc déjà réunies par construction, et la quatrième se franchira sans bruit.

En conséquence, cette analyse est réexaminée au moins une fois par an, et à chaque fois que le portefeuille de clients change d'ordre de grandeur. Si la désignation devient obligatoire, elle sera faite, notifiée à l'Autorité de protection des données et inscrite ici.

Point de contact. Les questions relatives à la protection des données s'adressent à l'adresse du § 13. La personne qui y répond n'exerce pas les fonctions de délégué à la protection des données au sens des articles 37 à 39 du RGPD : nous préférons le dire plutôt que d'employer un titre auquel s'attachent des obligations que nous ne tenons pas.

---

4. Les données des visiteurs de bâtiments

Rappel : sur toute cette section, le responsable du traitement est l'organisation qui vous accueille, et nous agissons sur ses instructions.

4.1 Ce qui est réellement enregistré

Ce qui n'est jamais enregistré : la photo de votre pièce d'identité (§ 4.4), le numéro de votre pièce d'identité (§ 4.5), votre date de naissance, la date d'expiration de votre document, votre adresse, votre adresse e-mail.

Les deux dates ont été retirées le 20/08/2026 de la consigne envoyée au service de lecture, précisément pour qu'elles ne traversent pas un prestataire tiers.

4.2 Finalités

Tenir le registre des entrées et sorties du bâtiment ; permettre à l'accueil de contrôler un badge ; disposer d'une liste des personnes présentes en cas d'évacuation ; produire un export vérifiable pour un auditeur ; vous reconnaître lors d'une visite suivante afin de raccourcir l'enregistrement.

4.3 Base légale

C'est l'organisation qui vous accueille qui la détermine, pas nous — c'est le propre du rôle de sous-traitant. Selon l'établissement, il s'agira le plus souvent de son intérêt légitime à sécuriser ses locaux (art. 6.1.f), ou d'une obligation légale qui lui est propre (art. 6.1.c) — certains établissements de santé et certains sites industriels sont tenus de tracer les présences.

Nous ne pouvons pas vous dire laquelle s'applique à votre visite. Demandez-la à l'organisation : elle doit pouvoir vous répondre.

Où ce choix est-il consigné ? Pas dans le produit : aucun écran ne demande à un client d'inscrire sa base légale, et aucune colonne de la base ne la stocke. Il l'est par écrit dans le contrat de sous-traitance — l'accord prévu par l'article 28 du RGPD, qui constitue l'annexe 2 de nos conditions générales de vente et oblige chaque organisation cliente à déterminer et documenter cette base. Nous le précisons parce que la question se pose vraiment : sans l'un ou l'autre, personne ne pourrait prouver que le choix a été fait.

Et une précision de calendrier, parce qu'elle change la portée de la phrase ci-dessus : nous n'avons aucun client en exploitation à la date de ce document, et le recueil de l'acceptation de ces conditions n'est encore branché sur aucun écran. Ce contrat existe donc comme texte, pas encore comme signature. Il sera conclu avec la première organisation cliente, avant toute mise en service.

4.4 La photo de votre pièce d'identité — le trajet exact

C'est le passage le plus important de ce document, et il commence par une correction.

Certains de nos textes commerciaux ont affirmé que la photo de votre pièce d'identité « ne quitte jamais votre appareil ». C'est faux. Nous le corrigeons ici, et nous corrigeons ces textes. La phrase vraie est : la photo est transmise, et elle n'est jamais conservée. La différence entre les deux compte, et c'est exactement pour cela que nous l'écrivons plutôt que de la contourner.

La photo est facultative. Vous pouvez toujours saisir vous-même votre nom, votre prénom et le numéro de votre document : aucune image n'est alors transmise à personne. Le registre notera simplement que votre identité est déclarée et non vérifiée, et l'organisation qui vous accueille peut avoir de bonnes raisons d'exiger le niveau supérieur.

« Facultative » veut dire facultative dans le produit, et il faut être précis. Aucun réglage ne permet à une organisation cliente de rendre la photographie obligatoire : le parcours laisse toujours la saisie manuelle ouverte. Une organisation peut évidemment demander la pièce à son comptoir — c'est sa décision et sa responsabilité —, mais c'est une consigne d'accueil, pas une règle que le logiciel fait respecter.

Ce qui se passe si vous prenez la photo

1. Vous photographiez la face qui porte votre photo et votre nom — le recto d'une carte, la page photo d'un passeport. Le verso n'est jamais demandé, et c'est délibéré : sur le verso d'une carte belge, les modèles de lecture rendent six fois sur sept le numéro de registre national à la place du numéro de carte. Précision, parce que la version courte de cette phrase était inexacte : ce que le produit refuse n'est pas « le verso », qu'il ne sait pas reconnaître à coup sûr, mais tout numéro qui a la forme d'un registre national. Un tel numéro est écarté avant toute suite : il ne vous est pas renvoyé, aucune empreinte n'en est calculée et aucun jeton de lecture n'est émis. Le nom et les prénoms lus, eux, vous sont bien proposés pour pré-remplir le formulaire, et la lecture est classée non vérifiée.
2. Votre téléphone réduit l'image (1600 pixels de côté, JPEG qualité 85) avant tout envoi.
3. L'image est envoyée à notre serveur, dans le corps d'une requête chiffrée en transit (HTTPS).
4. Notre serveur la transmet à OpenRouter, un service qui achemine la requête vers des modèles de lecture automatique. Elle est envoyée à deux modèles en parallèle — par défaut deux modèles Google (gemini-2.5-flash-lite et gemini-3.1-flash-lite). Pourquoi deux : un nom de famille ne porte aucune clé de contrôle, rien ne peut dire qu'il a été mal lu, et deux lectures indépendantes qui concordent valent mieux qu'une lecture confiante. C'est une mesure d'exactitude, pas de confort.
5. Les modèles rendent un texte. La photo est abandonnée.

Ce qui n'arrive jamais à cette image, chez nous

Elle n'est écrite sur aucun disque, placée dans aucune file d'attente, mise dans aucun cache, et inscrite dans aucun journal. Elle n'existe qu'en mémoire vive, le temps de la requête, borné à 15 secondes au maximum.

Les quatre chemins par lesquels le contenu d'une requête peut fuir dans un journal ont été examinés un par un et fermés : le journal d'accès n'écrit que la méthode, l'adresse et la durée ; le message d'erreur du client HTTP n'est jamais recopié, parce qu'il peut contenir la requête donc l'image ; une erreur de validation ne rapporte que le nom du champ et la taille maximale, jamais la valeur ; et la seule ligne journalisée après une lecture porte le niveau atteint, le motif d'un éventuel refus, l'organisation, le bâtiment et le nom des modèles — jamais les champs lus.

Ce qu'il en reste, une fois la lecture faite

• Un jeton de lecture temporaire, valable 10 minutes, à usage unique, lié à l'affichette QR par laquelle vous êtes entré. Il transite par votre navigateur. Il contient l'empreinte du numéro, le type et le pays du document, le nom et les prénoms lus, et une date d'expiration. Il est signé — donc infalsifiable — mais non chiffré : il est lisible par qui le détient, c'est-à-dire par votre téléphone.
• Après votre enregistrement : les lignes décrites au § 4.1.
• Rien d'autre. Ni l'image, ni le numéro.

La limite que nous ne masquons pas

Ce que nous garantissons chez nous est vérifiable dans notre code, et un auditeur peut le contrôler. Ce qui se passe chez le prestataire de lecture ne l'est pas au même degré, et nous refusons de le présenter comme une garantie.

La seule protection demandée aujourd'hui est un paramètre transmis dans la requête — data_collection: "deny" — qui indique à OpenRouter de ne pas acheminer la requête vers un fournisseur de modèle qui déclarerait conserver les données. C'est un filtre d'acheminement, et il porte sur le fournisseur de modèle.

Trois choses qu'il ne fait pas, et qu'il faut savoir :

• il ne dit rien de la journalisation par OpenRouter lui-même, qui est un réglage de compte que son interface de programmation n'expose pas — nous ne pouvons donc ni le lire, ni le prouver à un auditeur ;
• il ne fixe aucun fournisseur en particulier : l'acheminement reste libre parmi ceux qui déclarent ne rien conserver, et l'identité du point de service retenu n'est pas journalisée de notre côté ;
• il ne vaut pas un engagement contractuel de non-conservation (zero data retention). Un réglage distinct existe chez OpenRouter et porte cette exigence-là ; notre requête ne l'emploie pas aujourd'hui.

Le contrat qui nous lie à OpenRouter, et ce qu'il contient

Il y en a un, et il est automatique : l'accord de sous-traitance d'OpenRouter (openrouter.ai/data-processing-agreement) précise qu'utiliser le service vaut acceptation de ses termes. Aucune signature séparée n'est requise, et le transfert vers les États-Unis s'y appuie sur les clauses contractuelles types de la Commission européenne, module 2 (responsable de traitement vers sous-traitant).

Ce que ce contrat ne contient pas, et qu'un délégué à la protection des données demandera en premier : aucun engagement de non-conservation propre à notre compte. Nous n'avons signé aucun accord de zero data retention avec OpenRouter. Sa politique de confidentialité affirme ne pas conserver les fichiers image « au-delà de la durée nécessaire à l'acheminement de la requête, sauf pour la détection d'abus, la sécurité, la facturation ou une obligation légale » — quatre exceptions, dont la première n'est assortie d'aucune durée chiffrée. Nous rapportons cette phrase parce qu'elle est leur engagement public ; nous ne la présentons pas comme la nôtre.

Ce que nous avons effectivement réglé sur notre compte, relevé le 23 août 2026. Nous préférons décrire cet écran plutôt que de le résumer, parce que c'est le point que nous jugeons nous-mêmes le plus sensible de tout le service.

OpenRouter propose deux familles de réglages distinctes. La première, Zero Data Retention, force le routage vers des points de terminaison qui ne stockent rien : aucun de ses cinq interrupteurs n'est activé sur notre compte. La seconde, Data Training, décide vers quels points de terminaison une requête peut partir selon ce qu'ils font des données : « points de terminaison payants qui s'entraînent sur les données » est désactivé, « points de terminaison qui publient les requêtes » est désactivé, mais « points de terminaison gratuits qui s'entraînent sur les requêtes » est activé.

Ce dernier réglage n'atteint pas les photos de pièces d'identité, pour deux raisons cumulatives et vérifiables : les deux modèles que nous utilisons sont des modèles payants (google/gemini-2.5-flash-lite et google/gemini-3.1-flash-lite, services/api/src/lib/openrouter.ts:120-123), et chaque requête porte de toute façon data_collection: "deny", qui interdit le routage vers un fournisseur qui conserve.

Nous le mentionnons quand même, parce qu'un réglage de compte laissé ouvert est une protection qui repose entièrement sur le code : le jour où quelqu'un ajoute un appel sans ce paramètre, plus rien n'arrête la requête. Désactiver ce réglage ne coûterait rien — aucun de nos modèles n'est concerné — et c'est ce que nous recommandons.

Dans quel pays cette lecture a-t-elle lieu ? Nous ne le savons pas, et nous le disons

C'est le point le plus inconfortable de ce document, et le contourner serait pire que l'écrire.

• OpenRouter, Inc. est établie à New York, États-Unis. Elle n'est pas certifiée au EU-U.S. Data Privacy Framework — la décision d'adéquation par laquelle une entreprise américaine est traitée comme si elle était dans l'Union. Le transfert repose donc entièrement sur les clauses contractuelles types.
• Le fournisseur de modèle réellement retenu n'est pas fixé par notre requête. Pour les modèles que nous utilisons, il existe un point de service européen ; notre appel ne l'épingle pas, et l'acheminement peut donc changer d'un appel à l'autre sans que rien ne le signale.
• Le pays de traitement n'est déclaré par personne. Le registre des fournisseurs d'OpenRouter ne renseigne aucun centre de données pour Google, et les conditions de Google prévoient que les données « peuvent être stockées de manière transitoire ou mises en cache dans tout pays où Google ou ses agents exploitent des installations ». Les mêmes conditions réservent en outre une journalisation, de durée non chiffrée, aux seules fins de détecter les usages interdits.

Ce traitement doit donc être présumé hors Union européenne, et nous ne pouvons pas garantir aujourd'hui le pays où la lecture est effectuée (voir § 8). Un commentaire de notre code note qu'une observation du 20/08/2026 indiquait un acheminement vers Google AI Studio : c'est une constatation faite un jour donné, pas une configuration, et nous refusons de la présenter comme une garantie.

Rappel, parce qu'il change tout pour vous : la photo est facultative. Si vous saisissez vos données à la main, aucune image n'est transmise à personne et rien de ce paragraphe ne vous concerne.

4.5 Le numéro de votre pièce d'identité

Il n'est jamais conservé. Trois éléments indépendants le garantissent : aucune colonne de la base ne peut le contenir ; le contrat de données de l'enregistrement ne comporte aucun champ destiné à le recevoir ; et le code qui le manipule ne l'écrit nulle part.

Ce qui est conservé est une empreinte irréversible (HMAC-SHA-256), calculée à partir du numéro, du type et du pays du document, et d'une clé secrète stockée hors de la base de données. Cela signifie que quelqu'un qui obtiendrait une copie complète de la base ne pourrait pas retrouver les numéros : la clé n'y est pas.

Cette empreinte sert à une seule chose : vous reconnaître à votre prochaine visite sans vous redemander qui vous êtes.

Précision de vocabulaire, parce que nos écrans emploient encore le mot « chiffré » : il s'agit d'un hachage, pas d'un chiffrement. Un chiffrement se déchiffre ; ceci ne se défait pas. Le produit est ici meilleur que ce que le mot laisse entendre, mais le mot est inexact et sera corrigé.

Le numéro apparaît une seule fois en clair : il vous est renvoyé sur votre téléphone pour pré-remplir le formulaire, afin que vous puissiez le corriger si la lecture s'est trompée. Il n'est pas renvoyé à l'enregistrement, et disparaît ensuite.

4.6 Combien de temps ces données sont-elles conservées ?

Chaque organisation cliente règle elle-même une durée de conservation applicable aux données personnelles de ses visites : 365 jours par défaut, réglable entre 30 et 3650 jours. Ce réglage vaut pour toute l'organisation, et non bâtiment par bâtiment. Passé ce délai, la purge vide de la visite votre nom, votre prénom, le motif, la note de l'accueil et le code de votre badge, et coupe le lien avec votre fiche. La ligne subsiste avec sa date, son bâtiment, son statut, la personne visitée et la société que vous aviez déclarée — cette dernière n'est pas effacée par ce mécanisme, contrairement à ce qu'une version antérieure de ce paragraphe indiquait. Le lien qui vous rattache à ce client, lui, est bien supprimé : c'est lui qui portait votre numéro de téléphone, la société et l'identifiant de votre téléphone.

Quand cette purge s'exécute-t-elle ? Chaque nuit, à 2 h 30 UTC, dans la même tâche planifiée que la clôture des visites oubliées, la signature et l'horodatage du registre — et délibérément avant la signature, parce que la purge inscrit elle-même une entrée au registre depuis la base de données, donc sans signature : la faire passer après ferait basculer le registre du client en « non certifiable » jusqu'au lendemain.

Chaque purge qui efface quelque chose écrit dans le registre de l'organisation une entrée retention_purge portant la durée appliquée, la date de coupure et trois compteurs — visites anonymisées, liens supprimés, fiches supprimées. Aucune donnée personnelle n'y figure, et c'est par cette entrée que le client vérifie lui-même que la purge a bien tourné chez lui.

Un fait de calendrier que nous devons à nos lecteurs. Ce branchement date du 22/08/2026. Avant cette date, la fonction de purge existait dans la base de données mais rien ne l'appelait : le produit affichait une durée de conservation, la faisait régler par le client, l'enregistrait — et ne l'appliquait jamais. Une version antérieure de cette page le disait, et nous ne l'effaçons pas de la mémoire du document : un lecteur a le droit de savoir depuis quand une promesse est tenue.

Ce que nous pouvons attester, et ce que nous n'attestons pas encore. Nous constatons le branchement dans le code de la tâche nocturne. Nous n'avons pas encore observé un cycle complet en conditions de production, faute d'exploitation réelle : la première organisation cliente le constatera dès sa première nuit, à la présence de l'entrée décrite ci-dessus dans son registre.

Durées des autres éléments :

4.7 Décision automatisée et profilage (art. 22)

Deux modèles de langage lisent votre pièce, et ils produisent un niveau de vérification d'identité — déclarée, probable ou vérifiée — qui est scellé dans votre badge et dans le registre. Il faut donc dire ce que ce niveau décide, et ce qu'il ne décide pas.

• Vous restez l'autorité sur ce qui est écrit. Les champs lus vous sont proposés ; vous les corrigez et vous validez, et c'est votre validation qui enregistre la visite. Si vous corrigez le nom lu, la prétention à la vérification retombe — la correction reste permise, c'est l'étiquette qui tombe avec elle.
• Le niveau ne vous ouvre ni ne vous ferme aucune porte par lui-même. Aucun mécanisme du produit ne refuse un enregistrement, ne bloque une entrée ni ne retire un badge en fonction de ce niveau : il est inscrit, jamais opposé. Décider qui entre reste le geste de l'organisation qui vous accueille, exercé par une personne.
• Aucun profilage. Rien n'évalue votre comportement, votre fiabilité ou votre fréquence de passage, et aucun score n'est calculé.

Il n'y a donc, à ce jour, aucune décision produisant des effets juridiques ou vous affectant de manière significative qui soit prise sur le seul fondement d'un traitement automatisé. Si une organisation cliente décidait un jour de conditionner l'accès à ce niveau, elle en deviendrait responsable et devrait vous en informer elle-même.

---

5. Le registre inaltérable face au droit à l'effacement

C'est la tension centrale de ce produit : il vend un registre qu'on ne peut pas réécrire, à des organisations dont les visiteurs ont le droit d'être effacés. Voici comment elle est résolue — et le point essentiel est que les deux ne se rencontrent jamais.

5.1 Deux couches, et le registre ne porte aucun contenu personnel

ClearlyAccess sépare strictement :

• Les tables métier, qui portent votre nom, votre société, votre téléphone, le motif de votre visite. Elles sont modifiables et effaçables.
• Le registre d'audit, qui est en ajout seul : on ne peut ni le modifier, ni en supprimer une ligne, ni le vider. Trois verrous posés dans la base de données elle-même refusent toute tentative, y compris celles qui contournent les mécanismes habituels de PostgreSQL. Ils ne sont pas absolus : qui possède la table peut les désactiver, ce qui laisse une trace dans le catalogue de la base. C'est décrit sans détour au § 10.3, et c'est la raison d'être de l'horodatage externe.

Le registre ne contient aucun contenu personnel — mais il porte des références, et il faut le dire. Une entrée porte l'organisation, le rang, le type d'événement, la date, le bâtiment, et — à la place du contenu — l'empreinte SHA-256 de ce contenu, plus l'empreinte de l'entrée précédente qui enchaîne les lignes les unes aux autres, plus une signature électronique. Le texte lui-même — celui qui contient votre nom — n'y est jamais.

Deux colonnes, en revanche, sont des données à caractère personnel au sens du RGPD, et présenter le registre comme totalement dépourvu de telles données serait faux :

• l'identifiant de l'agent ou de l'administrateur qui a accompli le geste, lorsque c'en est un — ce n'est pas votre donnée à vous, c'est celle d'un salarié de l'organisation cliente, et c'est à ce titre que nous devons la déclarer ;
• l'identifiant de la visite concernée, qui, tant que la visite n'a pas été anonymisée, désigne une ligne où figure votre nom. Après anonymisation ou purge, cette référence ne mène plus à personne — c'est précisément ce qui rend l'effacement possible.

Conséquence à ne pas masquer : ces deux références vivent dans une table en ajout seul, et aucun mécanisme automatique ne les efface — ni la purge de rétention, ni le droit à l'effacement. Ce que l'effacement retire, c'est ce qu'elles désignent — et c'est précisément ce qui le rend possible : effacer votre nom ne modifie pas une seule ligne du registre.

Leur durée n'est pas pour autant illimitée : le contrat conclu avec chaque organisation cliente fixe la conservation du registre à la durée du contrat, prolongée de cinq (5) ans, au terme desquels il est supprimé (article 10.4.e des conditions générales de vente). Cette durée est motivée par le besoin de preuve de l'organisation cliente — c'est ce qui lui permet de faire recalculer un verdict de chaîne sur un export qu'elle a conservé —, et elle vaut aussi pour l'identifiant du salarié auteur de chaque entrée, dont elle ne peut pas être dissociée. C'est un engagement contractuel exécuté à la main, non une purge programmée.

5.2 Ce que fait exactement une demande d'effacement

Dans l'ordre, pour l'organisation concernée :

1. Vos visites sont anonymisées : nom, prénom, motif, note de l'accueil et code de badge sont mis à zéro, et la visite est marquée comme anonymisée à cette date. La ligne subsiste, avec le bâtiment, les horaires, le statut, la société que vous aviez déclarée, la personne que vous étiez venu voir et le niveau de vérification atteint.
2. Votre lien avec cette organisation est supprimé — c'est lui qui portait votre numéro de téléphone, la société déclarée et l'identifiant de votre téléphone.
3. Votre fiche du référentiel de personnes est supprimée, et avec elle l'empreinte de votre pièce d'identité — mais seulement si plus aucune autre organisation ni aucune visite non purgée ne s'y rattache.
4. Une trace de l'effacement est inscrite au registre.

⚠️ Le point 3 est conditionnel, et nos écrans le présentent aujourd'hui comme inconditionnel. Si vous êtes un prestataire qui visite deux hôpitaux et que vous demandez l'effacement chez l'un des deux, l'empreinte de votre pièce d'identité reste en base, puisque le second hôpital vous connaît encore. Elle ne disparaîtra qu'avec votre dernier rattachement. C'est la conséquence directe du fait que ces deux hôpitaux sont deux responsables de traitement distincts (§ 5.5), et le texte affiché dans l'application sera corrigé pour le dire.

5.3 Pourquoi l'effacement lui-même laisse une trace

Cela peut sembler contradictoire. Ça ne l'est pas.

Un registre dont les lignes peuvent disparaître sans que rien ne le signale ne prouve plus rien : il ne permet plus de distinguer « il ne s'est rien passé ce jour-là » de « la ligne a été retirée ». Ce que le registre certifie, c'est qu'aucune visite n'a été ajoutée, retirée ni réordonnée en catimini. Une suppression silencieuse détruirait cette propriété pour tout le monde, y compris pour les autres visiteurs.

L'entrée d'effacement contient donc : la mention que la demande vient d'un visiteur, la date, et trois compteurs — combien de visites anonymisées, combien de liens supprimés, la fiche a-t-elle été supprimée ou non.

Elle ne contient ni votre nom, ni aucun identifiant vous désignant — pas même l'identifiant interne de votre fiche, puisque c'est exactement ce qui vient d'être effacé et que le registre, lui, ne se réécrit jamais.

Autrement dit : le registre prouve qu'un effacement a eu lieu, jamais le vôtre.

5.4 Ce qui est perdu, et ce qui ne l'est pas

Après un effacement, l'empreinte inscrite dans le registre ne peut plus être recalculée : le texte qui l'a produite n'existe plus. Ce qui est perdu est donc la capacité de rejouer le contenu — pas l'intégrité.

Le vérificateur du registre distingue explicitement les deux cas et ne les confond jamais :

Un auditeur peut donc toujours vérifier qu'aucune visite n'a été ajoutée, supprimée ou réordonnée, y compris sur une période où des visiteurs ont exercé leur droit à l'effacement. C'est ce que le produit vend, et l'effacement ne l'entame pas.

5.5 L'effacement ne vaut que pour une organisation

Demander l'effacement chez l'hôpital A ne retire rien chez l'hôpital B. Ce n'est pas une limitation technique : ce sont deux responsables de traitement différents, chacun avec sa propre finalité, sa propre base légale et sa propre durée de conservation. Nous ne pouvons pas effacer chez B des données dont B répond, sur la seule instruction d'une demande adressée à A.

Pour être effacé partout, il faut le demander partout — depuis le badge de chaque visite.

5.6 Pourquoi l'effacement est refusé tant que vous êtes dans le bâtiment

Si une de vos visites est en cours — vous êtes entré et vous n'avez pas signalé votre sortie — la demande d'effacement est refusée.

La raison est la sécurité des personnes. Tant que vous êtes physiquement à l'intérieur, votre nom figure sur la liste des personnes présentes en cas d'évacuation. Vous effacer de cette liste pendant que vous êtes dans le bâtiment reviendrait à ce que les secours ne sachent pas qu'il faut aller vous chercher. L'article 17.3 du RGPD prévoit précisément ce type de limite.

Ce refus est temporaire, et ce n'est pas un refus de droit — c'est un ordre d'opérations. L'écran vous dit quoi faire : clôturez votre visite depuis votre badge, puis revenez sur cette page. L'effacement s'applique alors immédiatement.

Et si vous partez sans clôturer, le blocage ne dure pas : une tâche automatique nocturne ferme d'office les visites restées ouvertes trop longtemps — 24 heures par défaut, réglable par bâtiment de 1 à 720 heures. Vous pouvez donc revenir le lendemain.

Une réserve, parce qu'elle est réelle : ce réglage peut être désactivé par une organisation cliente. Si elle le fait, une visite jamais clôturée reste ouverte indéfiniment, et l'effacement demeure bloqué tant qu'elle l'est. Dans ce cas, adressez-vous à l'organisation, qui peut clôturer la visite depuis son portail.

5.7 Une limite qu'il faut connaître : les visites enregistrées au comptoir

Le parcours automatisé du § 9 repose sur le code de votre badge. Il ne fonctionne que si vous vous êtes enregistré vous-même, depuis votre téléphone.

Si c'est l'agent d'accueil qui vous a enregistré à sa place — parce que vous n'aviez pas de téléphone, ou que le comptoir a été plus rapide — votre visite n'est rattachée à aucune fiche du référentiel de personnes, et les deux routes automatiques répondent « badge inconnu ». Vous ne pouvez alors exercer ni votre droit d'accès ni votre droit à l'effacement par ce chemin.

Dans ce cas, adressez-vous directement à l'organisation qui vous a accueilli : elle reste le responsable du traitement, elle a accès à ses propres registres, et nous l'assistons à sa demande, comme le prévoit l'article 28.3.e du RGPD.

Nous ne présentons pas cela comme une propriété du produit : c'est un défaut, et il est à corriger. Un droit dont l'exercice dépend de la manière dont on a été enregistré n'est pas un droit bien servi. Deux issues sont possibles — rattacher les visites créées au comptoir au référentiel de personnes, ou ouvrir à ces visites un autre chemin d'exercice. Aucune n'est faite à ce jour, et nous préférons l'écrire que de laisser un visiteur le découvrir devant un message d'erreur. En attendant, le contrat de sous-traitance conclu avec chaque organisation cliente — l'annexe 2 de nos conditions générales de vente — met ces demandes-là à sa charge, avec notre assistance.

---

6. Nos propres traitements — ici, nous sommes responsables

6.1 Comptes des utilisateurs de nos clients

Données : adresse e-mail, nom complet, rôle (administrateur ou accueil), organisation, et les éléments d'authentification gérés par notre fournisseur (mot de passe sous forme d'empreinte, jetons de session).

Finalité : donner accès au portail, authentifier, tracer qui a enregistré ou contrôlé une visite.

Base légale : exécution du contrat qui nous lie à l'organisation (art. 6.1.b).

Conservation : pour la durée du contrat. Aucune suppression automatique n'existe aujourd'hui — un compte se désactive, il ne s'efface pas de lui-même. Voir § 15.

6.2 Invitations

Lorsqu'un administrateur invite un collègue : adresse e-mail, nom, rôle, une empreinte du lien d'invitation (jamais le lien lui-même), et les dates d'envoi et d'acceptation. Base légale : exécution du contrat. Conservation : aucune purge automatique à ce jour.

6.3 Prospects du site vitrine

Quand vous remplissez notre formulaire de démonstration : nom, organisation, adresse e-mail, message et langue.

Finalité : vous répondre. Base légale : mesures précontractuelles prises à votre demande (art. 6.1.b).

Destinataires : notre hébergeur, qui archive la soumission ; notre service d'envoi d'e-mails, qui nous notifie ; et — voir ci-dessous — Meta.

6.4 Attribution publicitaire vers Meta — un traitement que nous devons déclarer

Ce traitement n'a jamais été mentionné dans aucun de nos textes. Il l'est ici.

Lorsque vous arrivez sur notre site vitrine depuis une publicité Meta (Facebook, Instagram), deux choses se produisent :

1. L'identifiant de clic placé par Meta dans l'adresse est conservé 90 jours dans le stockage local de votre navigateur. Ce n'est pas un cookie, et ce n'est pas un traceur inter-sites : il ne sert qu'à rattacher une demande de démonstration à la publicité qui l'a précédée.
2. Si vous remplissez ensuite le formulaire, notre serveur envoie à Meta un événement indiquant qu'une demande a eu lieu, contenant l'empreinte SHA-256 de votre adresse e-mail, cet identifiant de clic, un identifiant d'événement, l'horodatage et l'adresse de la page.

Ne sont transmis ni votre nom, ni votre organisation, ni votre message — cette exclusion est délibérée et codée.

Nous devons cependant être clairs sur deux points. Une adresse e-mail hachée reste une donnée à caractère personnel : Meta la réidentifie par construction, c'est même la fonction de l'envoi. Et il s'agit d'attribution publicitaire, pas de mesure d'audience — le raisonnement « pas de cookie, donc pas de bandeau » porte sur les cookies et ne règle pas à lui seul la question de la base légale de ce transfert.

Ce traitement ne concerne que le site vitrine et ses prospects. Il n'existe ni dans l'application des visiteurs, ni dans celle de l'accueil. Aucune donnée de visiteur de bâtiment n'est jamais envoyée à Meta.

Sa base légale, dite sans habillage. Nous nous fondons sur notre intérêt légitime (art. 6.1.f) à mesurer l'efficacité de nos annonces, et aucun consentement n'est recueilli aujourd'hui sur le site vitrine. Deux précisions que nous devons à un lecteur exigeant : l'analyse de mise en balance qu'exige cette base — peser notre intérêt contre vos droits, par écrit — n'est pas encore formalisée ; et la conservation de l'identifiant de clic dans votre navigateur relève de la réglementation dite « vie privée et communications électroniques », qui peut appeler un consentement là où le RGPD seul s'en passerait. Ce point est en cours d'arbitrage, et l'une des issues envisagées est le retrait pur et simple de cet envoi.

Ce que vous pouvez faire dès maintenant, sans attendre cet arbitrage : vous opposer à ce traitement (art. 21) en nous écrivant à l'adresse du § 13 — nous y donnons suite sans vous demander de motif. Vider les données du site dans votre navigateur supprime par ailleurs l'identifiant de clic conservé.

---

7. Adresses IP

Notre interface de programmation reçoit et journalise l'adresse IP publique des appareils qui s'y connectent — donc celle de votre téléphone lorsque vous vous enregistrez. Elle sert à deux choses : le journal technique de notre hébergeur, et la limitation du débit, qui empêche qu'une même source sature le service (cette seconde utilisation est en mémoire vive uniquement, sans aucune conservation).

Aucun journal ne contient de donnée de visiteur : ni nom, ni numéro de téléphone, ni identifiant de personne, ni code de badge, ni contenu de pièce d'identité. Cela a été vérifié route par route. La demande d'effacement, en particulier, journalise le fait et l'organisation, jamais l'identifiant de la personne — puisque c'est précisément ce que l'on vient d'effacer.

Deux exceptions, sur nos propres données et non sur celles des visiteurs. Elles concernent toutes deux un salarié d'une organisation cliente — pour qui nous sommes responsable de traitement (§ 2.2) — et jamais un visiteur :

• la route qui ouvre un espace client écrit l'adresse e-mail du compte créé dans le journal technique, avec l'identifiant de l'organisation ;
• la route qui révoque une affichette QR écrit l'identifiant du compte qui opère la révocation, avec l'identifiant du jeton et le motif invoqué.

Ce sont les deux seules données personnelles journalisées par notre interface. Une version antérieure de ce paragraphe n'en déclarait qu'une et écrivait « c'est la seule » : c'était inexact, et les conditions générales de vente déclaraient déjà les deux. Elles vivent le temps de rétention des journaux de notre hébergeur. Aucun filtre de masquage n'est configuré sur le journal à ce jour : cette limite figure au § 15. Nous préférons décrire une exception que revendiquer un « aucun » que le code contredit.

Combien de temps ces journaux vivent-ils ? Ils sont tenus par notre hébergeur, Netlify, dont l'accord de sous-traitance (annexe II, § 5.A) fixe une conservation de 90 jours en ligne, puis un an hors ligne. Cette durée est celle de l'hébergeur : nous ne la choisissons pas, et nous ne pouvons pas la raccourcir par configuration.

---

8. Destinataires, sous-traitants ultérieurs et transferts hors UE

Nous ne vendons aucune donnée et n'en communiquons à aucun tiers à des fins commerciales. Les seuls destinataires sont les prestataires techniques nécessaires au fonctionnement du service.

Deux mots de vocabulaire avant le tableau, parce qu'ils commandent sa lecture. Un sous-traitant ultérieur est le sous-traitant de notre sous-traitant : Supabase héberge chez Amazon Web Services, donc AWS en est un, et il doit être nommé. Les clauses contractuelles types (CCT) sont le contrat modèle publié par la Commission européenne (décision 2021/914) qui autorise un transfert de données vers un pays n'offrant pas une protection jugée équivalente. Le Data Privacy Framework (DPF) est, lui, une décision d'adéquation du 10 juillet 2023 : une entreprise américaine qui s'y certifie est traitée comme si elle était dans l'Union, et le transfert n'a alors plus besoin de CCT.

OpenTimestamps n'est pas une société, et c'est utile de le savoir. C'est un protocole ouvert, sans personne morale, sans conditions d'utilisation : il n'y a donc personne avec qui signer un accord de sous-traitance, et aucun n'est nécessaire, puisque rien de personnel ne sort. Les calendriers publics sollicités sont opérés par Peter Todd, par Eternity Wall (Milan, Italie) et par Catallaxy (Québec, Canada). Ils reçoivent 64 caractères hexadécimaux et rien d'autre — le code refuse d'envoyer quoi que ce soit qui n'ait pas exactement cette forme.

Ni itsme ni le portefeuille européen d'identité ne sont branchés à ce jour : aucune donnée ne leur est transmise.

Les sous-traitants de nos sous-traitants. Chacun des prestataires ci-dessus publie sa propre liste, qu'il met à jour, et c'est elle qui fait foi ; nous la joignons au contrat de sous-traitance remis à chaque client (art. 28.2), dont l'article 13.1 des conditions générales de vente nomme déjà chaque entité contractante, sa région de traitement et l'instrument qui encadre le transfert. Deux points relevés le 23/08/2026 méritent d'être connus sans attendre : Supabase déclare notamment Amazon Web Services, Cloudflare, Google et Supabase, Inc. (assistance) — sans indiquer de pays pour aucun d'eux, ce qui est une lacune de son document et non du nôtre ; et Resend déclare vingt-deux sous-traitants, tous établis aux États-Unis, dont deux fournisseurs d'intelligence artificielle. Précision qui compte : les données de visite ne transitent pas par Resend — il ne reçoit que des adresses e-mail de salariés de nos clients et l'empreinte d'horodatage envoyée à chaque ancrage (§ 6.2, § 10.3) ; elles vivent en revanche bien dans l'infrastructure de Supabase, donc chez Amazon Web Services à Francfort. Un délégué à la protection des données attentif le verra de toute façon : mieux vaut qu'il le lise ici.

Une réserve sur les certifications DPF ci-dessus, et elle vaut d'être lue. Les trois mentions de certification (Netlify, Stripe, Resend) proviennent des déclarations écrites de ces prestataires, relevées à leur source le 23/08/2026. Nous n'avons pas pu les recouper avec le registre officiel dataprivacyframework.gov, dont l'interface de programmation ne répondait pas ce jour-là. Une auto-déclaration n'est pas une vérification : un certificat peut avoir été retiré sans que la page du prestataire soit à jour. Les clauses contractuelles types, elles, s'appliquent dans tous les cas.

Transferts hors Union européenne

Les données de visite sont stockées dans l'Union européenne, à Francfort. Cette phrase est exacte, et elle est plus étroite qu'il n'y paraît — trois précisions la complètent, et aucune n'est un détail.

1. Le stockage n'est pas le traitement — et les deux sont en Europe. La base de données est à Francfort ; le calculateur qui lit, écrit, signe et enchaîne ces données est une fonction serveur hébergée par Netlify, et elle s'exécute dans la même région : eu-central-1, Francfort. Au sens du RGPD, la simple consultation est déjà un traitement — c'est pourquoi la question de la région d'exécution se pose, et pourquoi la réponse ne se déduit pas de l'emplacement de la base.

(Relevé le 23/08/2026 auprès de Netlify, et non dans nos fichiers de configuration : functions_region vaut eu-central-1 pour les quatre sites du service. Nous le précisons parce que la région n'apparaît PAS dans nos fichiers de déploiement — c'est un réglage du compte d'hébergement, et quiconque chercherait la réponse dans notre code conclurait à tort que la région par défaut américaine s'applique. Trois de ces quatre sites s'exécutaient effectivement dans cette région par défaut — us-east-2, en Ohio — jusqu'à leur bascule le 23 août 2026 ; celui qui traite des données personnelles parmi eux est le site public, dont la fonction relaie le formulaire de contact. Nous ne sommes pas en mesure d'établir depuis quand le service applicatif lui-même, qui porte toutes les données de visite, est en Europe.)

2. La photo de votre pièce d'identité, si vous la prenez. Elle est transmise à un service de lecture dont le pays de traitement n'est pas établi et doit être présumé hors Union européenne (§ 4.4). Elle n'est jamais conservée, et ce transfert n'a pas lieu si vous saisissez vos données à la main.

3. L'administration de la base. L'entité qui nous fournit la base de données est singapourienne et prévoit un traitement possible aux États-Unis et à Singapour pour le support et la supervision — quand bien même les données, elles, restent à Francfort.

Dans tous ces cas, le transfert s'appuie sur les instruments nommés dans la dernière colonne du tableau : décision d'adéquation lorsqu'elle existe, clauses contractuelles types sinon.

---

9. Vos droits, et comment les exercer réellement

9.1 Si vous êtes un visiteur : depuis votre téléphone, sans compte

Vous n'avez ni compte, ni mot de passe, ni adresse e-mail à fournir. Votre badge est votre preuve. Depuis l'écran de votre badge, un bouton ouvre la page « Mes données ».

Le code de votre badge n'est jamais transmis dans l'adresse d'une requête à notre serveur : il voyage dans le corps, pour ne pas apparaître dans nos journaux d'accès.

Mais il figure dans l'adresse de la page de votre badge, qui est de la forme …/badge/<votre code> — c'est ce qui vous permet de rouvrir votre badge après avoir verrouillé votre téléphone. Il est donc dans l'historique de votre navigateur, et il peut apparaître dans l'en-tête d'origine envoyé par votre navigateur. Ce code ouvre l'accès à vos données et à leur effacement : ne le partagez pas, et videz les données du site si vous prêtez votre téléphone.

Ce que le droit d'accès vous montre : pour chacune de vos visites chez cette organisation — le bâtiment, la société déclarée, la personne visitée, le motif, les heures d'entrée et de sortie, le statut et le niveau de vérification d'identité.

Ce qu'il ne vous montre pas, et pourquoi :

• La note écrite par l'accueil est exclue. Elle est rédigée par l'organisation sur son propre registre d'exploitation, peut concerner des tiers ou son organisation interne, et l'article 15.4 réserve les droits d'autrui. Elle est en revanche effacée lorsque vous demandez l'effacement.
• La page décrit ensuite en toutes lettres trois catégories qui ne tiennent pas dans un tableau de passages : l'empreinte du numéro de votre pièce, votre numéro de téléphone et l'identifiant de votre appareil si vous les avez fournis, et le registre d'audit.
• Ce qu'elle omet encore, et qui devrait y figurer : le type et le pays de votre document, la date de validité de votre badge, et vos dates de première et de dernière visite chez cette organisation. Ces trois éléments sont conservés (§ 4.1) et ne vous sont aujourd'hui montrés nulle part. C'est une lacune du produit au regard de l'article 15, pas une exclusion volontaire ; elle est inscrite au § 15. En attendant qu'elle soit comblée, demandez-les à l'organisation qui vous a accueilli, ou à nous : nous les fournirons.

Sur la rectification, une précision honnête : elle ne peut pas être un simple remplacement. Le nom inscrit sur une visite est un instantané pris au moment de votre enregistrement, et c'est ce texte-là dont l'empreinte est scellée dans le registre. Le corriger ne peut donc prendre la forme que d'un événement de correction ajouté au registre, non d'une réécriture. Ce mécanisme existe dans le produit, mais il est aujourd'hui réservé au portail de l'organisation.

9.2 Si vous êtes un utilisateur d'une organisation cliente, ou un prospect

Écrivez-nous (§ 13). Nous répondons dans le délai d'un mois prévu par l'article 12.3.

9.3 Si vous avez été enregistré au comptoir

Voir le § 5.7 : adressez-vous à l'organisation.

---

10. Sécurité

10.1 En transit

Toutes les communications sont chiffrées en HTTPS. Les applications et le site imposent en outre HSTS sur un an. La liaison entre notre interface et la base de données impose le chiffrement dès que la base n'est pas locale.

10.2 Le cloisonnement entre organisations clientes

C'est la partie la plus solide de l'édifice, et elle ne repose pas sur du filtrage applicatif — c'est-à-dire pas sur une ligne de code qu'un défaut pourrait contourner.

Trois défenses volontairement redondantes :

1. La sécurité au niveau des lignes est activée et forcée sur toutes les tables métier, dans le moteur PostgreSQL lui-même. Une requête ne peut pas voir les données d'une autre organisation.
2. Le compte de connexion de l'application n'a aucun privilège permettant de contourner cette règle, et c'est vérifié au démarrage : l'interface refuse de démarrer si elle détecte le contraire. Ce contrôle existe parce qu'un test d'attaque avait fait tomber tout le cloisonnement sans modifier une seule ligne de code, en changeant seulement un paramètre de connexion.
3. Des clés étrangères composites rendent une référence croisée entre deux organisations impossible, même si une règle d'accès était mal écrite.

Le contexte d'organisation est posé à l'échelle de la transaction, jamais de la connexion : une connexion rendue au pool ne peut pas emporter le contexte d'un autre client. En l'absence de contexte, la base lève une erreur au lieu de rendre « aucune donnée » — un silence pouvant se confondre avec un résultat vide.

Les tables qui n'ont pas de colonne d'organisation, comme le référentiel de personnes, sont protégées différemment : une organisation ne peut y voir qu'une personne avec laquelle elle a un lien, et ne peut jamais énumérer le référentiel.

Un DPO posera ici une question précise, et voici la réponse exacte. « Le nom de mes visiteurs se retrouve-t-il dans une base commune à vos autres clients ? » — Oui pour la fiche de personne et l'empreinte de sa pièce, non pour tout le reste. Le référentiel de personnes est commun à l'ensemble de nos clients : c'est ce qui permet de reconnaître un visiteur déjà venu, et c'est aussi ce qui rend l'effacement de l'empreinte conditionnel (§ 5.2, point 3). Tout ce qui est propre à une relation entre un client et un visiteur — téléphone, société déclarée, badge, appareil, visites, motif, note d'accueil — est en revanche cloisonné par organisation. Aucun client ne peut lire, énumérer ni rapprocher les données d'un autre, et nous n'exploitons ce référentiel pour aucune finalité qui nous soit propre. Nous décrivons cette architecture plutôt que de la laisser découvrir en audit.

10.3 Intégrité du registre

Chaque entrée est chaînée à la précédente, signée électroniquement (Ed25519), et l'empreinte de tête est horodatée sur la chaîne Bitcoin via OpenTimestamps — ce qui rend impossible d'antidater une modification, y compris pour nous.

Une précision de rythme, parce que « quotidien » serait inexact. La tâche s'exécute chaque nuit à 2 h 30 UTC, mais elle n'ancre que les registres qui ont bougé : une organisation dont la tête de chaîne est déjà horodatée n'est pas resoumise, et une nuit sans nouvelle entrée ne produit donc ni ancrage, ni courrier. Ce n'est pas un défaut — la tête de la veille est déjà horodatée, et comme chaque maillon porte l'empreinte du précédent, horodater la tête horodate tout ce qui la précède.

La clé publique de signature est publiée avec l'algorithme et la description exacte de ce qui est signé, de sorte qu'un auditeur puisse vérifier lui-même, sans nous. Les clés retirées continuent d'être publiées : sans quoi une rotation de clé effacerait rétroactivement les preuves antérieures.

Ce que cet horodatage n'est pas. Ce n'est pas un horodatage qualifié au sens du règlement européen eIDAS : aucun prestataire de services de confiance certifié n'intervient, et la preuve n'a donc pas la force probante renforcée qu'eIDAS attache à un jeton qualifié. C'est une preuve technique vérifiable par quiconque, laissée à l'appréciation du juge. Nous le disons partout où le produit se décrit, plutôt que de laisser le mot « Bitcoin » faire croire à davantage.

Au 22/08/2026, l'ensemble des entrées du registre de production est signé. Avec une nuance de calendrier qu'un auditeur relèvera : les entrées écrites par la base elle-même — la clôture d'office d'une visite oubliée — naissent sans signature, parce que la clé privée n'est pas et ne doit pas être dans la base. Elles sont signées par la tâche nocturne, avant l'horodatage de la nuit. Entre leur écriture et ce passage, elles existent donc quelques heures sans signature. L'entrée qui trace un effacement, elle, est signée dans la même transaction que l'effacement.

Une limite énoncée honnêtement : les verrous d'immuabilité sont des déclencheurs de base de données, et un compte administrateur de la base pourrait les neutraliser le temps d'une opération. C'est la raison d'être de l'horodatage externe : ce qui a été ancré sur Bitcoin ne peut plus être réécrit discrètement. Nous préférons décrire cette limite plutôt que laisser croire à une inviolabilité absolue.

10.4 Gestion des clés

La clé privée de signature n'est jamais stockée en base de données ni dans notre code source. En production, l'interface refuse de démarrer si elle est absente. La clé publique est dérivée de la clé privée et jamais configurée séparément.

Point de transparence : il n'y a ni module matériel de sécurité, ni séparation des rôles sur cette clé. Elle est détenue par une seule personne.

10.5 Limitation de débit

Des compteurs par adresse IP et par affichette QR limitent le nombre de requêtes par minute, et un quota horaire par bâtiment limite les enregistrements en libre-service. Le multiplicateur qui assouplit ces limites pour les tests est ignoré en production — une protection qui se désarme par variable d'environnement n'est pas une protection.

---

11. Cookies et mesure d'audience

11.1 Cookies : aucun

Ni le site, ni l'application visiteur, ni le portail d'accueil ne déposent de cookie. Notre interface s'authentifie par en-tête, jamais par cookie, et les échanges entre domaines sont configurés pour ne transporter aucun élément d'identification implicite.

11.2 Stockage local sur votre appareil

Techniquement différent d'un cookie : ces éléments restent sur votre appareil et ne sont transmis à personne.

Une correction : un commentaire de notre code affirme qu'« aucun nom ni code de badge » n'est stocké localement. C'est exact de l'identifiant d'appareil, mais faux du badge, qui contient bien votre nom et votre société. Le tableau ci-dessus fait foi. Pour effacer ces éléments : videz les données du site dans votre navigateur.

11.3 Mesure d'audience

Nous utilisons Umami, une solution de mesure d'audience sans cookie, que nous hébergeons nous-mêmes sur analytics.wepion.be — un domaine qui nous appartient. Aucun prestataire d'analyse tiers n'intervient donc, et aucune donnée de fréquentation n'est communiquée à un tiers. L'hébergeur de ce serveur et le pays où il se trouve ne sont pas établis par les vérifications de cette page ; nous les communiquons à qui les demande (§ 13), et nous les inscrirons ici.

• Sur le site vitrine : le suivi automatique des pages vues est actif.
• Dans les applications visiteur et accueil : le suivi automatique est désactivé, et seuls des événements d'étape sont envoyés (« tunnel ouvert », « enregistré », « sortie »…) avec pour seules propriétés la langue et, le cas échéant, un code de refus. Aucun nom, aucune donnée de visite.

Dans tous les cas, votre navigateur charge le script depuis ce serveur, qui reçoit donc votre adresse IP et le nom de votre navigateur.

Une réserve levée le 23 août 2026, et la réponse était mauvaise. Nous la racontons plutôt que de la faire disparaître.

Cette page portait jusque-là une réserve : le script de mesure étant chargé depuis notre serveur, c'est lui qui compose ce qu'il envoie, et nous ne pouvions pas affirmer qu'il n'y joignait pas l'adresse de la page. Or l'adresse d'une page du parcours visiteur contient le jeton de l'affichette QR du bâtiment.

Nous l'avons observé, en interceptant les envois réels de l'application en production. L'adresse partait en entier, jeton compris, à chaque étape du parcours. Le commentaire de notre propre code affirmait le contraire : désactiver le suivi automatique supprime bien l'envoi d'une vue de page, mais pas les propriétés jointes à chaque envoi manuel — et l'adresse en fait partie.

Corrigé le jour même : l'adresse transmise est désormais le chemin constant /v, qui identifie le parcours sans identifier le bâtiment, et le référent est vidé. Vérifié dans le fichier réellement servi par notre serveur, et non seulement dans notre code source.

Ce que cela laisse derrière. Les mesures enregistrées AVANT cette date contiennent ces jetons. Ils ne désignent aucune personne — ce sont des identifiants de bâtiment — mais ils dessinent la liste des sites de nos clients. Une organisation cliente qui souhaite leur suppression peut la demander (§ 13) ; nous n'attendrons pas cette demande pour purger cet historique.

Ce que nous affirmions déjà et qui reste vrai, parce que c'est notre code qui le décide : aucun nom, aucune donnée de visite et aucune donnée de pièce d'identité ne figure dans ces événements.

---

12. Réclamations

Si vous estimez que vos droits n'ont pas été respectés, vous pouvez introduire une réclamation auprès de l'autorité de contrôle.

En Belgique — Autorité de protection des données (APD) Rue de la Presse 35, 1000 Bruxelles contact@apd-gba.be — www.autoriteprotectiondonnees.be

Si vous résidez dans un autre État membre de l'Union européenne, vous pouvez également saisir l'autorité de contrôle de votre pays de résidence.

Attention à qui vous visez. Si votre réclamation porte sur une visite dans un bâtiment, elle concerne l'organisation qui vous a accueilli, qui est le responsable du traitement (§ 2.1). Si elle porte sur votre compte utilisateur ou sur une demande de démonstration, elle nous concerne.

Nous vous encourageons à nous écrire d'abord : la plupart des questions se règlent en quelques jours.

---

13. Nous contacter

Pour toute question sur cette politique ou sur l'exercice de vos droits :

info@clearlyaccess.eu — en indiquant « RGPD » dans l'objet du message, ce qui nous permet de l'identifier et de le traiter comme tel.

Par courrier : ICLICS SRL, Chemin du Beau Vallon 42, 5100 Namur, Belgique.

Nous répondons dans le délai d'un mois prévu par l'article 12.3 du RGPD. Rappel utile avant d'écrire : si votre demande porte sur une visite dans un bâtiment, votre interlocuteur est l'organisation qui vous a accueilli, et non nous (§ 2.3) — nous lui transmettons ce qui lui revient, mais vous gagnerez du temps en vous adressant directement à elle.

---

14. Modifications de cette politique

Nous mettons ce document à jour à chaque évolution du produit qui change la nature, la destination ou la durée de conservation des données. La date en tête indique la dernière révision. Les organisations clientes sont informées des modifications substantielles par le canal prévu au contrat.

---

15. Ce que ce produit ne fait pas encore

Un texte de conformité qui ne décrit que ce qui fonctionne n'apprend rien à celui qui doit décider. Cette section rassemble donc, en un seul endroit, les limites connues du produit au 23/08/2026 — celles qui changent quelque chose pour un visiteur, et celles qu'un délégué à la protection des données doit peser avant de signer. Chacune est décrite en détail dans la section indiquée.

Ce qui limite l'exercice de vos droits

Ce qui est conservé plus longtemps qu'on ne le souhaiterait

Ce que nous ne pouvons pas garantir sur nos prestataires

Ce que nos écrans disent encore de travers

Nous les corrigeons ; en attendant, c'est cette page qui fait foi, et non eux.

• Des textes commerciaux affirment que la pièce d'identité « ne quitte pas le téléphone ». C'est faux : elle est transmise, et jamais conservée (§ 4.4).
• L'écran d'effacement annonce la suppression de l'empreinte de votre pièce sans dire qu'elle est conditionnelle (§ 5.2).
• Le parcours visiteur emploie le mot « chiffré » là où le produit fait un hachage : le produit est meilleur que le mot, mais le mot est inexact (§ 4.5).
• Une page de tarifs annonce une durée de conservation réglable par bâtiment : le réglage est par organisation (§ 4.6).

---

Ce document a été rédigé à partir du code source, en datant chaque vérification. Là où le produit ne fait pas ce qu'un texte promettait, c'est le produit qui est décrit — jamais la promesse.