Aller au contenu
MobilityOS
Commencer gratuitementCommencer

Ce que MobilityOS stocke, et ce qu'il ne stocke pas

Confidentialité et non-stockage des données personnelles : comment l'application garantit que les informations d'un client ne sont sauvegardées nulle part.

Version 2026 Auteur Guilhem Normand Document public

Résumé

Cette note répond à une question : « Comment l'application garantit-elle que les informations client ne sont sauvegardées nulle part ? »

La réponse est structurelle : l'application agit comme un miroir numérique. Ce que le client saisit se reflète en temps réel sur l'écran du conseiller. Cela ne passe par aucun serveur ni base de données. Seule l'étiquette affichée dans la file d'attente transite par le coordinateur, le temps de l'attente. Dès la fermeture de la session, les données disparaissent.

Architecture du miroir

La transmission passe par WebRTC (Web Real-Time Communication), une connexion directe de pair à pair standardisée par le W3C.

Téléphone du visiteur saisit ses informations Canal WebRTC, chiffré de bout en bout DTLS · de navigateur à navigateur serveur jamais sur le chemin du formulaire Écran du conseiller affiche en temps réel
Le coordinateur met les deux appareils en relation et tient la file d'attente. Le formulaire, lui, ne passe jamais par lui.

Aucun serveur intermédiaire ne touche le contenu du formulaire. Le coordinateur de l'agence ne connaît que la file : ordre d'arrivée, étiquette affichée, poste qui prend en charge.

Ce qui est stocké, ce qui ne l'est jamais

Le registre, ligne par ligne. Tout ce qu'un client saisit est à gauche ; tout ce qu'une licence d'agence exige est à droite.

Jamais stocké
  • Adresse, code postal, ville du clientjamais enregistrés chez nous ; l'autocomplétion interroge Photon by Komoot depuis le téléphone
  • Téléphone et e-mailde pair à pair ; transmis au prestataire d'envoi si le conseiller déclenche une vérification, jamais enregistrés
  • Adresse temporaire (hôtel, Airbnb)même canal de pair à pair
  • Numéro de réservation du clientde pair à pair uniquement, en mémoire vive du terminal, effacé à la fermeture
Stocké
  • Nom de l'agence (licence)en KV (pas une donnée personnelle)
  • Date d'expiration de la licenceen KV (pas une donnée personnelle)
  • Date et version d'acceptation des CGUen KV, sur le compte de l'entreprise (registre légal)
  • Télémétrie de la console d'accueilen KV, par site : empreinte d'appareil, ville et position arrondie, 30 jours ; puis des cumuls sans date

Le compte d'une entreprise enregistre ses sites, son personnel, ses mesures d'usage et ses journaux. Le détail et les durées de conservation sont dans la politique de confidentialité.

Garanties techniques

4.1 Aucune base de données clients

Aucune fonction n'écrit ce qu'un visiteur saisit dans le formulaire d'accueil. Le compte d'une entreprise enregistre ses sites, son personnel d'accueil et ses mesures d'usage. Ce contenu est listé, avec ses durées, dans la politique de confidentialité.

4.2 Chiffrement de bout en bout

WebRTC chiffre les données avec DTLS. Aucun nœud intermédiaire ne peut en lire le contenu.

4.3 Éphémère par design

Ce qu'un visiteur saisit ne vit qu'en mémoire de la console et disparaît à la fermeture de l'onglet. Rien n'en est écrit sur le poste. Sur son propre téléphone, seul le brouillon de sa saisie reste dans l'onglet, pour qu'un rafraîchissement ne l'efface pas. La file est tenue par le coordinateur de l'agence : ordre d'arrivée et étiquette affichée, jusqu'au retrait de la ligne.

4.4 Aucun journal du contenu

Ce qu'un visiteur saisit n'apparaît dans aucun journal : le formulaire ne traverse pas nos serveurs. Les en-têtes HTTP bloquent la mise en cache des pages de l'accueil et de la console (Cache-Control: no-store). Les mesures d'usage conservées comptent des gestes, sous une empreinte qui change chaque jour. Elles sont décrites dans la politique de confidentialité.

4.5 Vérification e-mail / SMS (optionnelle)

Pour vérifier un contact, l'application peut envoyer au client un e-mail de confirmation ou un SMS contenant un lien. L'envoi passe par un prestataire. L'adresse ou le numéro ne sert qu'à cet envoi : ils ne sont jamais écrits en base. Un jeton temporaire (30 minutes) relie le clic du client à la session, puis expire et disparaît. Côté conseiller, l'historique des vérifications reste en mémoire vive et s'efface à la fermeture.

Cycle de vie d'une donnée

Une adresse e-mail, de la première touche à la fermeture de l'onglet.

  1. Le client tape son e-mail.
  2. Le script empaquette les données en mémoire vive.
  3. L'objet part par le canal WebRTC chiffré, directement au conseiller.
  4. Le conseiller reçoit et affiche la donnée.
  5. Le bloc de formulaire ne part par aucune requête HTTP : il ne quitte le téléphone que par le canal chiffré.
  6. À la fermeture, l'écran du conseiller est vidé : il n'en existe aucune copie. Sur le téléphone, le brouillon de saisie disparaît avec l'onglet.

Conclusion

  • Respecte le principe de minimisation du RGPD (art. 5.1.c).
  • Aucune base de données de clients : le formulaire ne touche aucun serveur.
  • Canal de pair à pair, chiffré de bout en bout.
  • Rien de ce qu'un visiteur saisit n'est écrit en base. Ce que le compte de l'entreprise y enregistre est listé dans la politique de confidentialité.

Références de code

Les fichiers à lire pour vérifier cette note, et ce que chacun fait.

  • functions/api/check-license.jsVérification de licence et réglages du formulaire. Ne reçoit ni n'écrit ce qu'un visiteur saisit.
  • functions/api/admin-agencies.jsGestion des licences. N'écrit que les métadonnées KV.
  • functions/api/billing/terms.jsEnregistre la date et la version d'acceptation des CGU
  • functions/api/turn-credentials.jsGénère des identifiants TURN éphémères
  • src/retailer/Console du conseiller. Mention légale affichée.

Guilhem Normand · 2026 · Document public

Retour à l'accueil