Politique de confidentialité

1. Deux rôles, qui répond de quoi, et sur quelle base

Pour les données du compte du conseiller — son identité, ses adresses, son mot de passe, ses appareils, son abonnement —, l'éditeur est responsable du traitement.

Pour les fiches de clients, contrats, notes, rendez-vous et documents que le conseiller saisit ou dépose, c'est le conseiller qui est responsable du traitement : ce sont ses clients, et c'est lui qui les a informés. L'éditeur agit alors comme sous-traitant : il héberge et traite ces données pour le compte du conseiller, sur ses instructions, et n'en fait aucun autre usage.

Pour ces fiches, c'est donc le conseiller qui choisit la base légale de son traitement et la dit à ses clients : le plus souvent les mesures précontractuelles prises à leur demande et l'exécution du contrat qu'il leur conseille ou gère, les obligations légales de son métier, ou son intérêt légitime à prospecter et à recruter. Modelys agit alors sur ses instructions, que l'annexe « Sous-traitance des données » des conditions d'utilisation décrit.

Pour ce dont l'éditeur est responsable, chaque traitement repose sur l'une des bases de l'article 6 du RGPD. Fournir les données nécessaires à l'ouverture du compte est une condition pour l'ouvrir ; le reste est facultatif.

• le contrat (article 6.1.b) : ouvrir et faire fonctionner le compte — identité, adresses, mot de passe et second facteur, grade et rattachement, essai, abonnement et formation, réglages gardés avec le compte, suivi de l'équipe que l'article 4 décrit, messages entre collègues et messages d'aide, courriels de l'application, signature des présents textes, et les options que le conseiller prend ou installe lui-même : VERA, Modelys pour Mac, le script de la Dream Team, sa clé Google Places ;
• l'obligation légale (article 6.1.c) : la facturation de l'abonnement, et ce que le droit comptable et fiscal belge oblige à conserver ;
• l'intérêt légitime de l'éditeur (article 6.1.f), qui est de garder l'outil sûr, disponible et juste, et de faire vivre le partenariat du bureau : le journal des gestes et le journal des accès, les limites d'envoi et de débit, le relevé des erreurs, les journaux techniques de l'hébergement, les copies de sauvegarde, l'arrêt d'urgence et la prévention de la fraude — dont, si elle est activée, la vérification anti-robot de l'écran d'entrée — ; l'organigramme décrit avant l'inscription ; l'annonce des comptes à CORAA et ce que l'éditeur de CORAA lit des factures, que l'article 5 décrit. Chacun peut s'opposer à ces traitements pour des raisons qui tiennent à sa situation, comme dit à l'article 8 ;
• le consentement (article 6.1.a), donné par un geste que rien n'impose et repris d'un geste : l'adresse de l'agenda et l'interrupteur qui la confie au serveur, les notifications du navigateur, la date de naissance et la photo, les réponses aux tests du recruteur, la raison donnée de ne pas s'abonner, et ce que « Se connecter avec Modelys » apprend à CORAA. Le retirer — vider le champ, éteindre l'interrupteur, refuser les notifications — ne rend pas illicite ce qui a été fait avant.

2. Les données du compte

Pour ouvrir et faire fonctionner un compte, Modelys enregistre :

• le prénom et le nom, l'adresse personnelle qui sert d'identifiant et l'adresse professionnelle qui signe les synthèses ;
• le mot de passe, sous une forme hachée que personne ne peut relire, et les appareils enregistrés pour le second facteur — l'application d'authentification qui en donne le code ;
• le grade, la date de nomination, le rattachement dans la structure, le statut d'agrément et la personne agréée qui accompagne ;
• les dates de l'essai, de l'abonnement et de la période Starter, et l'état de la formation ; et, quand le conseiller décide de ne pas s'abonner, la raison qu'il en donne, lue par l'éditeur seul ;
• l'adresse iCal de l'agenda, seulement si le conseiller la règle lui-même — gardée avec son compte chiffrée sous son mot de passe, que l'éditeur ne peut pas ouvrir ; et, s'il allume lui-même l'interrupteur qui confie son agenda au serveur, une seconde copie chiffrée sous une clé de l'hébergement, pour que le serveur lise l'agenda application fermée ;
• l'empreinte des clés d'API remises à VERA — jamais la clé elle-même —, et celle des clés des programmes que le conseiller installe lui-même : Modelys pour Mac, le script de la Dream Team ;
• le journal des gestes qui engagent quelqu'un d'autre : reprise d'un portefeuille, ouverture d'une liste, signature de la présente politique ; et le journal des accès : qui a lu quelle fiche ou quelle liste, qui a exporté un fichier, qui a fermé un compte ;
• les réglages que le conseiller garde avec son compte pour les retrouver d'un appareil à l'autre : sa photo, sa date de naissance s'il la donne — l'équipe n'en apprend que le jour, jamais l'année —, sa carte de visite, sa signature, ses modèles de courriers et ses listes de prospection ;
• ce qu'il écrit à ses collègues dans l'outil — une tâche confiée et sa réponse, une réponse au mot du chef ou au sondage —, lu par ceux à qui c'est adressé ;
• s'il les passe, ses réponses aux tests de personnalité et de couleurs du recruteur, que sa structure lit pour rapprocher coachs et candidats, et qu'il retire lui-même quand il veut ;
• en formation, les questions que l'outil lui pose avant l'envoi d'une synthèse et ses réponses, lues par ceux au-dessus de lui — la question décrit une situation, jamais un client ;
• les places de l'organigramme qu'un chef décrit avant que la personne s'inscrive — prénom, nom, grade, responsable et, s'il la connaît, l'adresse électronique —, qu'un compte vient occuper à son inscription ;
• pour chaque navigateur où il accepte les notifications, l'adresse que fournit le service de notification de ce navigateur, et le type d'appareil ;
• les messages envoyés par le bouton d'aide — le texte, les captures d'écran jointes, la version de l'application et le type d'appareil —, et la réponse de l'éditeur ;
• le relevé des erreurs : quand l'application rencontre une erreur, son message, nettoyé de toute donnée de client, part avec la page, la version, le navigateur et l'identifiant du compte, pour que l'éditeur la corrige ; il n'est lu que par l'éditeur ;
• les journaux techniques de l'hébergement : l'adresse IP, l'heure et l'adresse demandée de chaque connexion, gardés le temps que fixent Supabase et Vercel.

3. Les données des clients

Le conseiller saisit dans ses fiches — clients et prospects — l'état civil, les coordonnées, la situation familiale et professionnelle, les contrats et leurs montants, les notes d'appel, les rendez-vous, et ce qui ressort d'un décompte ou d'un extrait déposé. S'y ajoutent, quand il les note, les revenus, la mutuelle, la personne qui a recommandé le client, et le lien avec la fiche de son conjoint. Un document déposé est lu en mémoire pour en extraire les chiffres ; le fichier lui-même n'est pas conservé — sauf les pièces d'un candidat, gardées comme dit à l'article 7. Noter qu'une personne est en incapacité de longue durée, indemnisée par la mutuelle, c'est noter une donnée de santé : le conseiller ne le fait que si son conseil en dépend.

Le conseiller ne saisit que ce dont il a besoin pour suivre son client, et s'engage à informer ses clients de l'existence de ce fichier et de leurs droits. Le client, lui, n'a ni compte ni accès à Modelys : il lit l'écran partagé pendant le rendez-vous, et reçoit ensuite la synthèse par courriel, que le conseiller envoie depuis sa propre messagerie.

Une fiche de candidat au recrutement porte en plus les notes prises pendant les entretiens et, s'il les a remplis, ses réponses aux questionnaires que le recruteur a choisis, deux au moins parmi trois : le formulaire d'entreprise, dix-sept questions dont son âge et des réponses écrites librement ; le test de personnalité des cinq grands traits, cinquante positions sur une échelle ; et celui des couleurs, seize positions. Un candidat invité plus tôt a pu remplir le questionnaire de personnalité interne d'avant : trente-deux positions sur une échelle, sans commentaire libre. Les questionnaires se remplissent sur une page ouverte par un lien personnel qui expire et ne sert qu'une fois ; le candidat n'a pas de compte, et cette page ne lit rien d'autre que son prénom et le nom de la personne qui l'a invité. Le résultat n'est pas une mesure de compétences et ne décide de rien : il sert la conversation de l'entretien suivant — à une réponse près, l'âge, parce que, comme le formulaire le dit, un collaborateur doit avoir vingt et un ans au moins. Les coordonnées du candidat servent aussi à lui écrire depuis Modelys : l'invitation, les courriers de recrutement.

Pendant un rendez-vous, le conseiller peut présenter un document qu'il a déposé — un PDF rangé dans un espace privé à son nom — et y écrire au stylet ; chaque page annotée est gardée en image avec la fiche du client, lue par qui lit la fiche, et effacée avec elle.

Pour prospecter, le conseiller peut chercher des professionnels autour d'une commune : leur nom, leur adresse et leur numéro, tels qu'ils les publient, reviennent de Google et restent dans ses listes de prospection ; ils ne deviennent une fiche que s'il l'ajoute.

4. Qui lit quoi

Les fiches d'un conseiller ne sont lisibles que par lui. Son chef de structure en voit le nombre, jamais le contenu. Ces règles sont appliquées par la base de données elle-même, ligne par ligne, et non par les écrans : un écran contourné ne lit rien de plus.

Ce que la structure voit de plus se compte, et ne nomme aucun client. Pour suivre son équipe et calculer ce qu'elle lui rapporte, le chef de structure — et chacun au-dessus de lui — lit le détail des contrats de sa structure sans rien qui désigne le client (produit, compagnie, prime, capital, dates, statut), les compteurs tirés des fiches — rendez-vous, recommandations, heures de formation — et, des comptes de son équipe, le nom, l'adresse, le grade et l'état de l'abonnement. Toute la structure apprend le jour d'anniversaire des collègues actifs qui ont donné leur date de naissance. L'éditeur, qui administre l'installation, voit ces chiffres et ces comptes pour toute l'installation, et le journal des accès sans le nom d'un client qui n'est pas le sien. Pour ces calculs, et pour les tournées de VERA, de CORAA et de l'agenda confié, le serveur lit lui-même les fiches : il n'en journalise rien, et n'en garde que ce que ces calculs rendent.

Au-delà, une fiche ne s'ouvre que dans les cas suivants, chacun décidé par la personne concernée — sauf la transmission de la liste d'un compte fermé, qui ne peut plus répondre :

• pendant sa période de découverte, la liste d'un Starter est lue, en lecture seule, par le recruteur qui l'a invité — son responsable direct —, et par personne d'autre ; si ce recruteur quitte, c'est le responsable sous lequel le Starter remonte qui la lit à sa place. Elle se referme au terme de la période, ou dès que le Starter prend son abonnement ;
• un conseiller peut ouvrir sa liste à son responsable direct, en lecture seule, jusqu'à une date qu'il choisit et qu'il peut refermer quand il veut ;
• quand un conseiller arrête, son responsable peut lui demander la reprise de son portefeuille, pour que ses clients gardent un suivi ; rien ne bouge tant que la personne n'a pas accepté, et un silence n'est pas un accord. Un compte fermé, lui, ne répond plus : quatorze jours après sa fermeture — le temps, pour quelqu'un fermé à tort, de le dire —, son chef de structure peut transmettre sa liste à quelqu'un de sa structure sans attendre d'accord, et l'éditeur le peut sans attendre ce délai. La fiche garde la trace de qui l'a bâtie ;
• un conseiller peut confier une fiche de candidat au collègue qui mène l'un des entretiens : celui-ci la lit et y écrit tant que la fiche est en recrutement, et l'un comme l'autre peut reprendre ce partage à tout moment. Le chef de structure, lui, lit les fiches de candidats de son équipe et y agit — avancer une étape, envoyer un courrier —, jamais sur une fiche de client, ni sur celle d'un candidat écarté ;
• en confiant une tâche à un collègue, un conseiller peut lui transmettre le nom et le numéro d'un client, et rien d'autre de la fiche ;
• par VERA, enfin, deux partages que l'article 5 décrit : les rendez-vous qu'un collègue renforce, et les clients qu'un conseiller confie à l'agréé qui l'a accompagné.

5. Les prestataires, et ce qui sort de Modelys

Modelys ne parle qu'au bureau, c'est-à-dire à sa propre base : ni analytique, ni traceur, ni police distante. Le navigateur n'a le droit d'appeler aucune autre adresse — hormis, si la vérification anti-robot de l'écran d'entrée est activée, celle de Cloudflare, dite plus bas. Ce qui doit sortir part donc du serveur, et seulement vers les prestataires suivants, chacun pour ce qui est dit de lui :

Deux bases distinctes, non fusionnées, hébergées séparément en Europe : celle de CORAA en France (eu-west-3), celle de Modelys en Irlande (eu-west-1).

Supabase, Vercel, Stripe, Resend et Google sont des sociétés américaines. La base et les fonctions du serveur tournent en Irlande ; mais un accès depuis les États-Unis, pour l'exploitation ou l'assistance, ne peut pas être exclu, et un courriel ou une notification passe par leurs serveurs, où qu'ils soient. Ces transferts s'appuient sur les garanties du RGPD : le cadre de protection des données entre l'Union européenne et les États-Unis pour les sociétés qui y adhèrent, et à défaut les clauses contractuelles types de la Commission européenne, que leurs conditions reprennent. GitHub, qui garde la copie hebdomadaire de la base, et Cloudflare, si la vérification anti-robot est activée, sont aussi des sociétés américaines, et les mêmes garanties s'y appliquent.

• Supabase héberge la base de données et l'authentification, ainsi que les fichiers déposés — pièces des candidats, présentations — dans des espaces privés rangés par conseiller, et le canal en direct entre deux appareils d'un même conseiller ;
• Vercel héberge l'application et sert ses pages ; ses fonctions tournent en Irlande, au plus près de la base ;
• GitHub, où vit le code de Modelys, garde une copie de la base hors de l'hébergeur : chaque semaine, une machine de GitHub lit la base — fiches, comptes et réglages, sans les fichiers déposés —, chiffre la copie et la range dans le dépôt de Modelys. Elle ne se lit pas sans une phrase secrète que l'éditeur a posée, et chaque copie est gardée 90 jours. Elle sert à rétablir le service si la base elle-même était perdue ;
• Stripe encaisse l'abonnement : Modelys ne voit jamais un numéro de carte, seulement l'état de l'abonnement. Stripe garde le nom, l'adresse de facturation, le moyen de paiement et les factures. L'éditeur de CORAA, rémunéré sur les abonnements, lit pour chaque facture payée le nom qui y figure, la date et sa part — ni le total payé, ni la carte ;
• Google, en lecture seule, pour l'agenda : seulement si le conseiller a réglé son adresse iCal, et rien n'est écrit dans l'agenda par Modelys. Le serveur le lit à chaque ouverture et, si le conseiller l'a confié, deux fois par heure application fermée ; de ce qu'il lit, il ne garde que ce qui se reporte sur les fiches. Quand le conseiller ajoute un rendez-vous à son agenda depuis Modelys, c'est la page de Google qui s'ouvre, déjà remplie — client, heure, lieu, invité —, et c'est lui qui l'enregistre ;
• Google Places, si le conseiller y pose sa propre clé, pour la prospection : le serveur envoie à Google le nom d'une commune et celui d'un métier, rien d'autre, et Google facture la recherche au conseiller ;
• Photon, le service de cartes édité par Komoot, pour trouver un lieu de rendez-vous : il reçoit les lettres tapées, et rien d'autre — ni le client, ni le conseiller ;
• Resend envoie les courriels de Modelys — confirmation d'adresse et mot de passe oublié, invitation et courriers de recrutement à un candidat, rappel avant la fin de l'essai, tâche confiée, réponse à un message d'aide : il reçoit l'adresse du destinataire et le texte du message. La synthèse au client, elle, part de la messagerie du conseiller ;
• ImprovMX transfère ce qui arrive à l'adresse de contact vers la boîte de l'éditeur, chez Google (Gmail), où arrivent aussi les messages d'aide ;
• les services de notification des navigateurs — Google, Apple, Mozilla, Microsoft — acheminent les notifications chiffrées de bout en bout : ils ne peuvent pas les lire. Une bannière ne nomme aucun client, sauf l'appel qui arrive sur le Mac du conseiller ;
• Cloudflare, si la vérification anti-robot de l'écran d'entrée est activée : le navigateur échange alors avec Cloudflare, sur cet écran seulement, son adresse réseau et des signaux techniques du navigateur, pour distinguer une personne d'un robot, et Supabase vérifie auprès de lui la réponse obtenue. Ni l'adresse électronique, ni le mot de passe, ni rien d'une fiche ne lui parvient. Tant qu'elle n'est pas activée, rien ne part vers Cloudflare ;
• VERA, l'assistant téléphonique, en option : sur publication explicite du conseiller, il reçoit le numéro, le nom, l'étape et une ligne de contexte de ses contacts, ainsi que les rendez-vous à venir — jour, heure, type d'entretien, prénom, nom et, si elle est cochée, la civilité. Jamais une adresse de client — seulement sa commune, quand le rendez-vous se tient chez lui —, une note ou un contrat. Les rendez-vous portent aussi le numéro du client, la langue dans laquelle lui écrire et leur lieu : son nom, s'il se tient à distance, et l'adresse du lieu choisi ou le lien de connexion ; une fois la première publication faite, le serveur en tient la liste à jour, application fermée. VERA renvoie l'issue de chaque appel — confirmé, messagerie, annulé, reporté et sa nouvelle date. Un collègue de la structure qui renforce les rendez-vous d'un conseiller — celui-ci le voit, et peut refuser — reçoit par son VERA ses rendez-vous du jour et du lendemain : nom, numéro, heure, type. Et l'agréé qui a accompagné un client reçoit, quand le conseiller le lui confie, son nom, son numéro et son étape, pour le reconnaître quand il appelle. VERA ne passe par aucun service de voix ni d'intelligence artificielle : ses messages partent en SMS ordinaires ;
• Modelys pour Mac, que le conseiller installe sur son ordinateur : il lit les rendez-vous du jour et du lendemain — nom, heure, type, sans numéro — et, quand un appel arrive sur le Mac, il envoie à Modelys le numéro ou le nom de l'appelant pour retrouver la fiche ; rien n'en est gardé ;
• le script de la Dream Team, si le conseiller l'installe dans son propre compte Google : il lit les en-têtes et la colonne des noms des feuilles de calcul de l'équipe, les envoie à Modelys, et y écrit les compteurs du conseiller que Modelys lui rend — des nombres, jamais un nom de client ;
• CORAA, l'outil de suivi de l'équipe édité par un partenaire du bureau : il reçoit les compteurs de production, la projection et l'état de formation. Il reçoit aussi l'annonce de chaque compte confirmé — adresse, prénom, nom, grade et adresse de son responsable — et ses changements d'adresse, ainsi que les compteurs du jour : rendez-vous planifiés et tenus, recommandations. Les rendez-vous du jour et du lendemain avec le nom du client n'y partent que si l'accord entre l'éditeur et CORAA le prévoit et que la liaison est activée ; ils portent alors aussi le numéro du client, l'heure, le type d'entretien et l'issue de l'appel de confirmation, et un entretien de recrutement n'y part que si ce partage est ouvert. Chaque envoi est signé. CORAA ne peut lire dans Modelys que la réponse d'accès — si une personne a accès, et pour combien de jours — et n'y modifie rien. Par « Se connecter avec Modelys », CORAA apprend en plus, quand la personne l'accepte, qui elle est — son adresse électronique — et rien d'autre : le jeton qu'il reçoit ne lit rien dans la base. En retour, par la même liaison signée, Modelys lit chez CORAA, pour chaque équipe désignée par un identifiant technique, des chiffres d'équipe : l'objectif hebdomadaire, le planifié et le réalisé par jour, l'objectif et le réalisé de production et les créneaux de pronostic, ainsi que le calendrier des mois de production. Jamais un nom, ni un identifiant de conseiller, ni une donnée de client. Pour une équipe de quelques personnes, ces chiffres peuvent néanmoins se rapporter à des personnes identifiables.

6. La sécurité

L'application n'est servie qu'en HTTPS, avec une politique de contenu qui interdit tout appel sortant vers une adresse inconnue. La base applique la sécurité de ligne sur chaque table. Le second facteur est proposé à chaque compte, la session se met en veille sur un poste laissé seul, et un voile masque le fichier pendant l'écran partagé. Les pièces des candidats et les présentations vivent dans des espaces de stockage privés, rangés par conseiller, et l'adresse de l'agenda est chiffrée. En cas d'attaque, l'éditeur peut fermer l'installation entière d'un geste. Chaque lecture d'une fiche ou d'une liste, chaque export et chaque fermeture de compte s'écrit au journal des accès, et la copie hebdomadaire de la base est chiffrée en AES-256 avant d'être rangée.

De son côté, le conseiller garde son mot de passe pour lui, ne partage jamais son compte, chiffre le disque de chaque poste qui ouvre Modelys, et signale à l'éditeur, dans les vingt-quatre heures, tout poste perdu ou tout accès qu'il n'explique pas.

7. Combien de temps

Les données du compte sont gardées tant que le compte est ouvert. Fermer un compte ne l'efface pas : son nom, son grade, ses contrats et son historique restent, parce qu'un contrat signé porte le nom de son vendeur et que les commissions de la structure en dépendent ; il quitte seulement l'organigramme et les listes où l'on travaille. Les données du compte sont effacées quand la personne le demande, sauf ce que la loi oblige à conserver — la facturation de l'abonnement, notamment.

Les fiches suivent leur conseiller. Quand il arrête, elles sont reprises par son responsable après son accord — ou, si son compte est fermé, transmises par son chef de structure —, comme dit à l'article 4, ou effacées avec le compte. D'ici là, elles restent en base, sous son nom. Une fiche effacée par le conseiller l'est pour de bon : Modelys ne garde pas de corbeille.

Les notes d'entretien et les réponses au questionnaire d'un candidat vivent avec sa fiche : elles s'effacent avec elle, et le lien qui permettait de répondre cesse de fonctionner de lui-même.

Les documents reçus d'un candidat — CV, lettre, diplôme — sont effacés deux mois après que sa candidature a été écartée, sans autre geste. Une candidature reprise avant ce terme garde ses documents. Ils s'effacent aussi avec la fiche.

Archiver une fiche ne l'efface pas : elle sort des listes, et son conseiller la retrouve. L'effacement est un geste à part, le seul qui détruise : il emporte la fiche, ses versions précédentes et ses diapositives, et ne laisse qu'une empreinte brouillée, qui ne dit pas qui est la personne, pour qu'un import ne la recrée pas. Tant qu'elle vit, une fiche garde ses dix dernières versions, que son conseiller seul relit pour réparer une erreur.

Le journal des accès est gardé un an ; le relevé des erreurs, trente jours. Les captures d'écran jointes à un message d'aide s'effacent trente jours après son traitement ; le message et la réponse restent. Les annonces du journal du bureau s'effacent après cent vingt jours. Une adresse d'agenda confiée au serveur s'efface dès que le conseiller reprend son agenda.

Une suppression demandée efface les données vives sous 48 heures. Les sauvegardes ne suivent pas ce délai : elles sont exclues de l'effacement immédiat, et se purgent par rotation en sept jours au maximum. L'éditeur s'interdit d'en restaurer une dans l'intervalle, sauf pour rétablir le service après un incident ; dans ce cas, toute suppression demandée entre-temps est appliquée à nouveau sous 48 heures. Passé ce délai, il n'en reste aucune trace — hormis l'empreinte brouillée d'une fiche effacée, dite plus haut, et la copie hebdomadaire dite ci-dessous.

La copie hebdomadaire chiffrée que garde GitHub (article 5) suit son propre rythme : chacune est gardée 90 jours, puis disparaît d'elle-même. Une donnée effacée peut donc y demeurer jusqu'à 90 jours, illisible sans la phrase secrète. L'éditeur s'interdit d'en restaurer une, sauf si la base elle-même est perdue ; dans ce cas, il prévient chaque utilisateur de la date de la copie restaurée, et toute suppression demandée depuis cette date dont il a la trace est appliquée à nouveau sous 48 heures.

8. Les droits, et à qui les demander

Chacun peut accéder aux données de son compte, les corriger, les faire effacer, en limiter le traitement, les recevoir dans un format lisible ou s'opposer à un traitement. Le fichier de contacts s'exporte depuis l'écran des données, à tout moment, en tableur ou en archive avec les pièces des candidats. Chacun relit aussi, dans le journal des accès, ses propres gestes et ceux des autres sur ses fiches. Un consentement se retire à tout moment, du geste qui l'a donné. Une opposition à un traitement fondé sur l'intérêt légitime de l'éditeur s'écrit à l'adresse ci-dessous ; l'éditeur y met fin, sauf motif impérieux — la sécurité de tous, notamment — qu'il explique.

Un client qui exerce ses droits s'adresse à son conseiller, qui répond avec les moyens de l'outil — corriger ou effacer la fiche. L'éditeur l'aide si besoin. Il en va de même pour un candidat au recrutement : il s'adresse à la personne qui l'a reçu en entretien. Pour effacer, le conseiller emploie l'effacement à la demande, et non l'archivage. Comment l'éditeur l'aide est écrit à l'article A.8 des conditions d'utilisation.

Pour tout ce qui concerne le compte, l'adresse est contact@modelysfinance.be. L'éditeur répond dans le mois. Toute personne peut aussi s'adresser à l'Autorité de protection des données, rue de la Presse 35, 1000 Bruxelles.

9. Ce qui reste sur l'appareil

Modelys ne pose aucun témoin de mesure d'audience ni de publicité. Il en pose trois, nécessaires à son fonctionnement : « modelys.langue », la langue de l'écran, gardé un an ; « modelys.connecte », qui dit seulement que ce navigateur a une session ouverte — la valeur « 1 », ni jeton ni identifiant —, pour montrer tout de suite le bon écran, posé quand une session s'ouvre, retiré quand elle se ferme, et gardé un an au plus ; et, pour un candidat qui ouvre le lien d'invitation reçu par courriel, un témoin de preuve que la page ne peut pas lire, gardé deux jours.

Le navigateur garde aussi, dans son stockage local, la session de connexion et les préférences de l'écran — les clés qui commencent par « modelys. » : thème, taille du texte, onglets, brouillons. Certaines touchent à des personnes : la clé Google Places du conseiller, l'adresse de son agenda, sa photo, et des copies des pièces d'un candidat. Sans bureau, les fiches elles-mêmes vivent dans la base du navigateur. Rien de cela ne quitte l'appareil par ce stockage ; tout s'efface avec les données du site dans le navigateur, et c'est pourquoi on ne laisse pas un poste partagé connecté.

Si la vérification anti-robot de l'écran d'entrée est activée, le navigateur charge, sur cet écran seulement, le programme de vérification de Cloudflare, qui peut lire et ranger dans le navigateur ce dont il a besoin pour distinguer une personne d'un robot, selon ses propres règles et sans servir à la mesure d'audience ni à la publicité : cela fait partie de la sécurité de l'entrée. Tant qu'elle n'est pas activée, rien de Cloudflare n'est chargé.

10. Les changements

Cette politique porte une date de version. Quand elle change, chaque personne la relit et la signe de nouveau à sa prochaine entrée dans Modelys ; la base garde, pour chaque compte, la version signée et le jour de la signature.

Un sous-traitant nouveau, qui recevrait des données des fiches, est annoncé avant d'en recevoir, comme le dit l'article A.7 des conditions d'utilisation.