Politique de confidentialité, données personnelles, cookies, traceurs, journaux techniques et statistiques locales — E-Motion France
Cette politique décrit de manière volontairement détaillée les traitements de données associés au service E-Motion France. Elle couvre les données personnelles, les données techniques, les données statistiques, les cookies, les stockages locaux, les journaux de sécurité, les événements de réservation, les calculs tarifaires, les interactions avec les formulaires, les données de paiement non sensibles, les preuves contractuelles et les traitements visibles uniquement depuis l’administration.
Le document est dense par conception. Il ne cherche pas à remplacer une interface courte de consentement, mais à expliquer de façon complète ce qui peut être collecté, pourquoi, dans quelles limites, avec quelles durées, avec quelles mesures de minimisation, et comment les préférences peuvent être gérées.
L’adresse IP peut constituer une donnée personnelle. Les données personnelles ne peuvent pas être conservées indéfiniment : leur durée de conservation doit être définie en fonction de l’objectif poursuivi, des obligations légales, des besoins de preuve, de sécurité, de facturation, de gestion commerciale, de gestion des litiges et d’amélioration du service.
Sommaire détaillé
- Objet général du document
- Responsable du traitement
- Donnée personnelle, donnée technique, donnée statistique
- Principes généraux
- Finalités générales
- Bases légales
- Catégories de personnes concernées
- Données de réservation
- Données collectées avant réservation validée
- Adresses, trajets, étapes et calculs tarifaires
- Données de champ formulaire et pauses de saisie
- Données de navigation
- Adresse IP complète
- Localisation approximative par IP
- Localisation GPS volontaire
- Identifiant visiteur
- Suivi complet de session
- Clics importants
- Événements Trajet
- Événements Mise à disposition
- Événements paiement non sensibles
- Péages, stationnement, frais externes
- Erreurs, bugs et logs techniques
- Cookies nécessaires
- Cookies de préférences
- Cookies de mesure d’audience
- Cookies marketing/publicité si activés plus tard
- Analytics local
- Analytics avancé configurable
- Données visibles uniquement admin
- Stripe et paiement
- Facturation et preuve
- Acceptation CGV
- Emails, téléphone, échanges
- Données passagers
- Incidents, salissures, dégradations, litiges
- Dashcam vidéo
- Sécurité du site
- Prestataires techniques
- APIs d’itinéraire, géocodage, routing
- Données non vendues
- Destinataires des données
- Hébergement
- Durées de conservation
- Cycle de vie des données
- Anonymisation / pseudonymisation / agrégation
- Droits des personnes
- Limites aux droits
- Retrait du consentement
- Gestion des préférences cookies
- Évolution de la politique
- Contact
1. Objet général du document
Cette politique explique comment E-Motion France peut collecter, utiliser, conserver, protéger, consulter, exporter, anonymiser ou supprimer des données dans le cadre d’un service de transport privé avec chauffeur. Elle couvre le tunnel de réservation, les demandes de trajet, les demandes de mise à disposition, les préférences de langue, les interactions avec les boutons, les calculs tarifaires, les erreurs techniques, les cookies, le stockage local, les journaux serveur, les statistiques locales et les documents de preuve.
Le document précise aussi les traitements qui peuvent être préparés dans l’administration mais désactivés par défaut, notamment l’analytics avancé avec IP complète, identifiant visiteur plus long, suivi de parcours, suivi de clics, suivi de champs observés, suivi d’adresses sélectionnées ou suivi de trajets calculés. Lorsqu’un traitement est seulement préparé, cela signifie qu’il existe comme paramètre technique ou option d’administration, mais qu’il n’est pas nécessairement actif.
Les données peuvent être traitées pour améliorer le site, améliorer l’expérience client, comprendre les besoins réels des visiteurs, adapter les tarifs, adapter les zones desservies, identifier les trajets les plus demandés, détecter les bugs, comprendre les abandons, améliorer l’ergonomie, adapter les services, améliorer les forfaits, adapter les contenus, protéger le site, prévenir les abus, gérer les réservations, gérer la facturation et gérer les litiges.
2. Responsable du traitement
Le responsable du traitement est E-Motion France, exploité par Alexandre BROSSARD, chauffeur VTC, SIREN 930 081 070, adresse professionnelle : 4 rue du vieux pont, 34270 Saint-Mathieu-de-Tréviers, France. Le contact opérationnel pour les demandes relatives aux données personnelles est : contact@e-motionfrance.fr.
Le responsable du traitement détermine les finalités et les moyens principaux des traitements : réservation, organisation de prestation, paiement, facturation, sécurité, relation client, amélioration du site, statistiques locales et preuve contractuelle. Certains prestataires techniques peuvent intervenir comme sous-traitants ou fournisseurs de services techniques selon leur rôle exact.
3. Donnée personnelle, donnée technique, donnée statistique
Une donnée personnelle est toute information se rapportant à une personne physique identifiée ou identifiable. Un nom, un numéro de téléphone, une adresse e-mail, une adresse postale, une position GPS, une adresse IP, un identifiant visiteur ou un identifiant de réservation peuvent être des données personnelles selon le contexte.
Une donnée technique est une information nécessaire ou utile au fonctionnement du site, à la sécurité, au diagnostic, à la compatibilité ou à l’exploitation : User-Agent, navigateur, système d’exploitation, taille d’écran, horodatage, page demandée, code d’erreur, temps de réponse, type d’appareil, résultat d’appel API, statut d’un webhook ou message d’erreur.
Une donnée statistique est une donnée utilisée pour comprendre un usage agrégé ou un comportement de navigation : nombre de visites, pages vues, sources, appareils, parcours, clics, abandons, calculs tarifaires, modes trajet/MAD, langues, erreurs fréquentes, périodes de demande, forfaits testés et options consultées.
4. Principes généraux
E-Motion France applique une logique de proportionnalité : collecter les données utiles au service, éviter les données inutiles, ne pas collecter les données de paiement bancaire sensibles, ne pas stocker les mots de passe dans les journaux, ne pas exposer de secret dans le JavaScript public, limiter les accès admin, documenter les traitements et prévoir des durées de conservation cohérentes.
Les données peuvent être strictement nécessaires, fonctionnelles, contractuelles, statistiques, de sécurité ou d’amélioration. Les données strictement nécessaires ne sont pas proposées comme désactivables dans le bandeau cookies. Les cookies, traceurs, identifiants techniques, journaux de navigation ou traitements non strictement nécessaires peuvent reposer sur le consentement lorsque celui-ci est requis. D’autres traitements peuvent reposer sur l’exécution du contrat, des mesures précontractuelles, une obligation légale ou l’intérêt légitime d’E-Motion France.
5. Finalités générales
Les finalités principales sont la réception des demandes, le calcul du prix, la création de réservation, la confirmation client, l’émission des PDF, l’envoi d’e-mails, la gestion du paiement, la gestion du paiement à bord, la gestion Stripe, la preuve d’acceptation des CGV, la facturation, la relation client et le suivi de la prestation.
Les finalités d’amélioration sont nombreuses : comprendre les zones de départ les plus demandées, les horaires les plus fréquents, les forfaits les plus testés, les options les plus utiles, les points de blocage dans le formulaire, les abandons avant paiement, les erreurs de calcul, les refus de devis obligatoire, les problèmes mobiles, les bugs d’autocomplétion, les différences entre Trajet et Mise à disposition et les besoins des clients. D’autres données peuvent être techniques, statistiques, fonctionnelles, contractuelles, de sécurité ou d’amélioration du service. La présente politique explique ces différentes catégories de manière détaillée.
- Améliorer l’ergonomie : champs trop longs, libellés ambigus, clics répétés, abandons.
- Améliorer les tarifs : zones demandées, horaires, forfaits, options, seuils devis.
- Améliorer la qualité : erreurs, performances, compatibilité navigateur, mobile.
- Protéger le site : abus, spam, surcharge, tentatives de contournement, erreurs répétées.
6. Bases légales
Selon les traitements, les bases légales peuvent être l’exécution d’un contrat, les mesures précontractuelles demandées par le client, une obligation légale, l’intérêt légitime, le consentement ou la défense de droits en cas de litige. Les réservations, les échanges nécessaires à la prestation, les preuves contractuelles et la facturation relèvent principalement du contrat, de mesures précontractuelles ou d’obligations légales.
La mesure d’audience peut être soumise au consentement lorsque les conditions d’exemption ne sont pas réunies. Certains traceurs strictement nécessaires au fonctionnement du site peuvent être utilisés sans consentement préalable. Certains outils de mesure d’audience très limités peuvent être exemptés de consentement lorsqu’ils respectent les conditions applicables. Lorsque le consentement est nécessaire, les traceurs concernés ne doivent pas être activés avant le choix de l’utilisateur.
Le mode analytics avancé, lorsqu’il inclut IP complète, identifiant visiteur durable, valeurs de champs, adresses sélectionnées, parcours détaillé ou suivi fin de session, est considéré comme plus sensible. Il doit être configuré prudemment, documenté, limité à l’administration, soumis aux catégories de consentement adaptées lorsque nécessaire et désactivé par défaut si le cadre juridique n’est pas confirmé.
7. Catégories de personnes concernées
Les personnes concernées peuvent être les visiteurs du site, les prospects demandant un tarif, les clients ayant validé une réservation, les passagers mentionnés dans une demande, les personnes qui contactent E-Motion France par e-mail, téléphone ou WhatsApp, ainsi que les utilisateurs administrateurs accédant à l’espace de gestion.
Une même personne peut passer par plusieurs états : simple visiteur, utilisateur du calcul tarifaire, prospect ayant commencé un formulaire, client ayant réservé, passager, interlocuteur dans un échange, personne liée à un incident, ou personne concernée par une demande de droit.
8. Données de réservation
Lorsqu’une réservation est validée, E-Motion France peut conserver les informations nécessaires à l’exécution de la prestation : nom, téléphone, e-mail, langue, type de réservation, départ, arrivée, étapes, date et heure de prise en charge, durée, forfait, options, mode de paiement, prix, détails tarifaires, commentaires utiles à la prestation, PDF client, PDF admin, bon de commande, statut Stripe ou statut de paiement à bord.
Les données de réservation validée peuvent être plus complètes que les données analytics avant validation. Cette différence est importante : avant validation, l’analytics local évite de stocker en clair les valeurs personnelles ; après validation, les informations nécessaires au contrat sont stockées pour exécuter, confirmer, prouver, facturer et suivre la réservation.
9. Données collectées avant réservation validée
Avant validation, l’objectif est de comprendre l’usage sans stocker inutilement les valeurs personnelles. Les événements peuvent donc indiquer qu’un champ a été commencé ou rempli sans conserver le contenu du champ : nom rempli oui/non, téléphone rempli oui/non, e-mail rempli oui/non, départ rempli oui/non, arrivée remplie oui/non, commentaire rempli oui/non, calcul tarifaire lancé oui/non.
En mode prudent, les valeurs telles que nom, téléphone, e-mail, adresse exacte, commentaire libre, données de paiement et données Stripe sensibles ne sont pas stockées dans l’analytics avant réservation validée. En mode analytics avancé, certains suivis plus détaillés peuvent être préparés, mais doivent être explicitement configurés et encadrés.
10. Adresses, trajets, étapes et calculs tarifaires
Les adresses de départ, d’arrivée et d’étapes sont nécessaires au calcul et à l’organisation d’un trajet simple. Elles peuvent être envoyées aux services de géocodage ou de routing côté serveur ou côté navigateur selon la fonctionnalité. Pour la mise à disposition, l’adresse d’arrivée est optionnelle et ne transforme pas la prestation en trajet simple.
Dans une mise à disposition, la distance OSRM entre départ et arrivée optionnelle peut servir uniquement à vérifier un seuil, déclencher une alerte, déclencher un devis obligatoire ou appliquer une majoration de seuil si elle est activée. Cette distance ne doit pas alimenter automatiquement les kilomètres utilisés, les kilomètres facturés ou les kilomètres supplémentaires de la mise à disposition.
Les trajets calculés peuvent inclure distance, durée, durée métier, provider retenu, péage estimé, parking estimé, approche chauffeur, retour admin, majorations, frais externes et montant final. Le client ne voit pas nécessairement tous les détails techniques, tandis que l’administration peut voir des détails utiles au contrôle.
11. Données de champ formulaire et pauses de saisie
Les champs formulaire peuvent générer des événements techniques : groupe de champs commencé, champ modifié, champ complété, erreur de validation, clic sur calcul tarif, soumission, abandon. Un mode avancé peut prévoir la détection d’une pause de saisie supérieure à une durée donnée, par exemple plus de 1 seconde, afin d’identifier les zones de friction.
Les valeurs de champs sont plus sensibles que les simples événements. Par défaut, l’analytics local ne stocke pas les valeurs personnelles en clair avant réservation validée. Si un réglage admin permet plus tard le suivi de valeurs de champs, il doit être désactivé par défaut, signalé comme sensible, limité au strict nécessaire, soumis au consentement ou à une base légale adaptée, et exclure les données de paiement, mots de passe, tokens, secrets, numéros de carte et données Stripe sensibles.
12. Données de navigation
Les données de navigation peuvent inclure la page visitée, le titre de page, le referrer limité au domaine, l’horodatage, la langue du navigateur, la langue du site, la largeur d’écran approximative, le mode clair/sombre, le type d’appareil, le navigateur, le système d’exploitation, le statut du consentement et un identifiant de session pseudonyme.
Ces données permettent de comprendre les pages consultées, les sources de visite, les appareils utilisés, les erreurs rencontrées, les parcours avant réservation, les abandons du tunnel et l’efficacité des pages d’information. Elles servent aussi à diagnostiquer les problèmes d’affichage mobile, de menu, de footer, de formulaire, d’autocomplétion ou de paiement.
13. Adresse IP complète
L’adresse IP complète peut être utile à la sécurité, à la prévention des abus, à l’analyse technique, au diagnostic de requêtes répétées, à l’identification d’un pays approximatif ou à la compréhension d’incidents. Elle reste cependant une donnée personnelle potentielle et doit être traitée avec prudence.
Par défaut, E-Motion France privilégie une IP hashée ou tronquée plutôt qu’une IP complète dans l’analytics local. Le mode IP complète peut exister comme option admin avancée, désactivée par défaut, avec avertissement visible, durée de conservation courte, accès réservé à l’administration et justification documentée. Si l’IP complète est activée, la politique doit expliquer la finalité, la durée, les accès, l’anonymisation et la suppression.
| Mode IP | Description | Utilisation recommandée |
|---|---|---|
| Aucune | Aucune IP n’est stockée dans l’analytics. | Maximum de minimisation. |
| Tronquée | Une partie de l’IP est supprimée pour limiter l’identification. | Statistiques et sécurité légère. |
| Hashée | L’IP est transformée par hachage avec sel tournant. | Détection de récurrence limitée. |
| Complète | L’IP complète est conservée temporairement. | Cas exceptionnel, sensible, durée courte. |
14. Localisation approximative par IP
La localisation approximative par IP peut permettre d’identifier un pays ou une zone générale. Elle ne correspond pas à une géolocalisation précise et peut être inexacte. Elle peut aider à comprendre la clientèle internationale, les langues utiles, les zones de demande, les anomalies de sécurité ou les accès inhabituels.
La localisation par IP ne doit pas être confondue avec une position GPS. Elle peut provenir de headers serveur, d’un hébergeur, d’un proxy technique ou d’un mécanisme local, sans nécessairement appeler un service tiers à chaque visite. Si un service tiers de géolocalisation IP est ajouté plus tard, il devra être documenté.
15. Localisation GPS volontaire
La localisation GPS peut être utilisée lorsque l’utilisateur clique volontairement sur un bouton de géolocalisation pour remplir une adresse de départ ou d’arrivée. Le navigateur demande alors une autorisation. Sans autorisation navigateur, le site ne doit pas accéder à la position GPS précise.
La position GPS volontaire peut être convertie en adresse ou utilisée pour faciliter la réservation. Elle ne doit pas être collectée comme tracking permanent. Elle ne doit pas être utilisée pour de la publicité, du retargeting ou une surveillance continue.
16. Identifiant visiteur
Un identifiant visiteur ou identifiant de session pseudonyme permet de relier plusieurs événements d’une même navigation : page vue, changement de langue, calcul tarifaire, abandon, retour sur le formulaire, clic WhatsApp ou soumission. En mode prudent, cet identifiant est court, aléatoire et limité dans le temps.
Un identifiant plus long peut être préparé en mode analytics avancé afin d’analyser des parcours sur plusieurs visites. Ce réglage est plus sensible, doit être documenté, configurable, désactivé par défaut et lié au consentement audience lorsque nécessaire. Il ne doit pas devenir un identifiant publicitaire et ne doit pas être partagé avec une régie marketing.
17. Suivi complet de session
Le suivi complet de session peut reconstituer l’ordre des pages visitées, les événements principaux, le temps passé, les clics importants, les modes choisis, les calculs lancés, les erreurs, les abandons et les réussites. Cette vision est utile pour comprendre pourquoi un visiteur quitte le formulaire, pourquoi un calcul échoue, ou pourquoi un forfait est mal compris.
Un suivi complet de session ne doit pas enregistrer de manière incontrôlée le contenu personnel complet du formulaire. Il doit privilégier des événements structurés, des booléens, des catégories, des clés techniques et des montants ou distances lorsque ceux-ci sont nécessaires à l’analyse du service.
18. Clics importants
Les clics importants peuvent inclure : appel téléphonique, WhatsApp, réservation, bouton “Dès que possible”, ajout d’étape, changement de langue, acceptation ou refus cookies, personnalisation cookies, choix d’un forfait, choix d’un pack km, choix d’une option, paiement à bord, paiement en ligne, soumission et demande de devis.
Le suivi des clics aide à comprendre les usages réels sans surveiller chaque mouvement de souris. En mode avancé, un suivi plus riche peut être préparé, mais il doit rester proportionné, limité aux boutons utiles, sans publicité, sans pixel externe et sans envoi à un tiers marketing.
19. Événements Trajet
Les événements Trajet peuvent inclure la visite de la page réservation, le mode Trajet sélectionné, l’ajout d’une étape, l’usage du bouton “Dès que possible”, le lancement du calcul tarifaire, la réussite du calcul, l’erreur de calcul, le choix du paiement, le clic de réservation, l’échec de validation et la réussite de réservation.
Les données tarifaires liées au Trajet peuvent comprendre distance, durée, durée métier, approche, retour, majorations, péages, parkings, frais externes et prix final. Les détails internes peuvent être visibles en admin et simplifiés côté client.
20. Événements Mise à disposition
Les événements Mise à disposition peuvent inclure le mode MAD sélectionné, le forfait demandé, le forfait appliqué, la bascule automatique forfait jour/nuit, le pack km sélectionné, l’option simple sélectionnée, le bouton “Dès que possible”, l’adresse d’arrivée renseignée oui/non, le seuil distance déclenché, le devis obligatoire, le calcul MAD, l’erreur MAD et l’abandon.
La MAD peut générer des données spécifiques : durée demandée, durée forfait, heures supplémentaires, prix heures supplémentaires, km inclus, pack km, km ajoutés, tarif km supplémentaire retenu, tarif heure supplémentaire retenu, options, prix options, distance départ/arrivée OSRM pour seuil uniquement, seuil dépassé, action seuil et message public.
21. Événements paiement non sensibles
Le site peut traiter des événements non sensibles liés au paiement : choix paiement à bord, choix paiement en ligne, création ou refus de session Stripe, retour paiement, statut général, identifiant de réservation et montant attendu. Ces informations servent à suivre le tunnel de réservation et à diagnostiquer les incidents.
Les données bancaires sensibles, numéros de carte, CVC, tokens secrets et informations complètes de carte sont traités par Stripe et ne sont pas stockés par E-Motion France. Les journaux internes ne doivent pas contenir ces éléments.
22. Péages, stationnement, frais externes
Des frais externes peuvent être estimés : péages, stationnement, frais d’accès, frais de parking POI, ou autres débours. Ces frais peuvent être ajoutés au prix lorsqu’ils sont fiables. Ils doivent être distingués des majorations commerciales.
Les péages et parkings estimés ne doivent pas être majorés comme la prestation. Ils peuvent être affichés séparément côté client et avec plus de détails côté admin : provider, montant, devise, disponibilité, notice, type POI, durée de référence et confiance.
23. Erreurs, bugs et logs techniques
Les logs techniques peuvent contenir des erreurs PHP, erreurs JavaScript, échecs d’API, timeouts routing, erreurs Stripe non sensibles, erreurs de validation, refus serveur, échecs d’écriture, problèmes PDF, problèmes email, état d’un webhook ou anomalies de format JSON.
Ces journaux servent à réparer les bugs, préserver la réservation publique, préserver l’admin, préserver les PDF, sécuriser les paiements, comprendre les incidents et prévenir les abus. Ils doivent éviter les secrets, tokens, mots de passe et données de carte.
24. Cookies nécessaires
Les cookies nécessaires permettent le fonctionnement essentiel du site : session admin, sécurité, conservation du choix cookies, fonctionnement du formulaire, prévention de certaines erreurs et maintien d’un état strictement nécessaire. Ils ne sont pas présentés comme désactivables dans le bandeau.
Le bandeau peut mentionner ces cookies comme toujours actifs. Le refus des cookies non essentiels ne doit pas empêcher les cookies nécessaires de fonctionner lorsque ceux-ci sont indispensables au service demandé.
25. Cookies de préférences
Les cookies ou stockages de préférences peuvent mémoriser la langue, le confort d’affichage, un brouillon local temporaire, un choix d’interface ou une préférence utilisateur. Ils relèvent du confort et ne doivent pas être confondus avec des traceurs marketing.
Le localStorage ou sessionStorage peut aussi être utilisé pour conserver temporairement un état de formulaire, uniquement côté navigateur, sans l’envoyer au serveur avant validation. Si un brouillon persistant est mis en place, une durée courte et une option d’effacement doivent être prévues.
26. Cookies de mesure d’audience
Les cookies ou identifiants de mesure d’audience peuvent permettre de comprendre les visites, pages vues, sources, appareils, langues, parcours et événements du tunnel de réservation. Lorsque la mesure d’audience n’est pas strictement exemptée, elle doit dépendre du consentement audience.
Le site peut utiliser un analytics local et, si l’utilisateur accepte la catégorie audience, Google Analytics 4 peut être chargé. Aucun outil d’audience non essentiel ne doit être activé avant le choix lorsque le consentement est nécessaire.
27. Cookies marketing/publicité si activés plus tard
À la date de cette politique, aucun script marketing, pixel Meta, pixel Google Ads, retargeting ou publicité externe n’est activé par E-Motion France. Une catégorie marketing/publicité peut être préparée pour un futur cadre, mais elle ne doit pas charger de publicité ni déposer de traceur marketing tant qu’aucun script actif n’existe et qu’aucun consentement valide n’est obtenu.
Si des partenaires locaux ou emplacements publicitaires sont étudiés plus tard, ils devront éviter le tunnel de réservation, éviter les popups, éviter les publicités intrusives et respecter l’image premium du service.
28. Analytics local
L’analytics local collecte et stocke des événements sur le serveur du site, dans un dossier non public. Il peut produire des fichiers mensuels de visites, événements et agrégats. Les événements sont validés côté serveur, limités en taille, protégés contre les abus et filtrés pour éviter les clés interdites.
Les événements autorisés peuvent inclure page vue, page quittée, clic téléphone, clic WhatsApp, clic réservation, changement de langue, choix cookies, visite réservation, mode sélectionné, groupe de champs commencé, calcul tarifaire, erreur, paiement choisi, soumission, succès, événement MAD, événement Trajet et abandon probable.
Le stockage local vise à rester utile et prudent : pas d’envoi à un tiers, pas de publicité, pas de données bancaires, pas de mot de passe, pas de secret, pas de nom/e-mail/téléphone/adresse exacte/commentaire en clair avant réservation validée.
29. Analytics avancé configurable
Un mode analytics avancé peut être préparé dans l’administration. Il peut prévoir : analytics basique actif, analytics avancé actif, IP complète active, identifiant visiteur actif, durée d’identifiant, suivi clics, suivi champs, suivi valeurs de champs, suivi adresses sélectionnées, suivi trajets calculés, suivi temps passé, suivi parcours session, GPS uniquement avec autorisation navigateur, conservation IP complète, conservation avancée, anonymisation automatique, purge et export CSV.
Les données souhaitées en mode avancé peuvent inclure IP complète, localisation approximative IP, identifiant visiteur plus long, pages vues, ordre des pages, clics importants, temps passé, parcours session, adresses sélectionnées dans l’autocomplete, départs/arrivées/étapes testés, trajets déclenchant un calcul automatique, date/heure testées, forfaits testés, options testées, champ avec pause supérieure à 1 seconde, valeur du champ si activée, erreur formulaire, abandon, mode Trajet/MAD, paiement choisi, seuil devis, bugs d’affichage, navigateur, OS, appareil et résolution.
Ce mode avancé reste configurable. S’il implique des données plus sensibles comme IP complète, valeurs de champs ou adresses sélectionnées, il doit être désactivé par défaut, contrôlé par l’admin, documenté, limité dans le temps, éventuellement lié au consentement audience, et réservé aux finalités d’amélioration, sécurité, ergonomie, qualité du service, compréhension des besoins clients, adaptation des zones desservies et adaptation des offres.
30. Données visibles uniquement admin
Certaines données ne sont pas affichées côté client mais peuvent être visibles dans l’espace admin : détails de calcul, provider routing, distance OSRM d’arrivée MAD, seuil appliqué, mode de tarification, forfait demandé, forfait appliqué, overrides admin, erreurs, logs, événements récents, IP hashée ou tronquée, et éventuellement IP complète si le mode sensible est activé.
L’accès admin doit être protégé. Les données admin ne doivent pas être exposées dans le JavaScript public, les pages publiques, les logs publics ou les fichiers téléchargeables sans contrôle.
31. Stripe et paiement
Stripe traite les paiements en ligne. Les données de carte sont saisies sur l’interface sécurisée de Stripe. E-Motion France peut conserver des identifiants techniques de session Stripe, d’intention de paiement, de statut, de montant attendu, de capture ou d’autorisation, mais pas les données de carte bancaire complètes.
Les webhooks Stripe peuvent mettre à jour une réservation, confirmer un paiement, indiquer un statut ou enregistrer une référence. Les secrets Stripe doivent rester dans des fichiers de configuration protégés et ne doivent pas apparaître dans les fichiers publics.
32. Facturation et preuve
Les données de facturation et de preuve peuvent inclure réservation, prix, mode de paiement, PDF client, PDF admin, bon de commande, version des CGV, date d’acceptation, e-mail de confirmation, détails utiles de prestation et pièces nécessaires à la gestion d’un litige.
Ces données peuvent être conservées plus longtemps que les événements analytics, notamment pour les obligations comptables, fiscales, contractuelles ou probatoires.
33. Acceptation CGV
La réservation publique exige l’acceptation des Conditions Générales de Vente. La preuve peut inclure : CGV acceptées oui/non, version 3.0, date d’entrée en vigueur, date/heure d’acceptation serveur, langue client, source public_form ou admin_manual, URL des CGV et clé de texte d’acceptation.
Les réservations créées depuis l’admin peuvent indiquer une vérification manuelle ou une acceptation hors site. Elles ne doivent pas permettre à un utilisateur public de forger une source admin_manual.
34. Emails, téléphone, échanges
Les échanges par e-mail, téléphone ou WhatsApp peuvent contenir des informations nécessaires à la prestation : détails de rendez-vous, demandes particulières, corrections, annulations, réclamations, justificatifs, modifications horaires, bagages, enfants, animaux ou informations de contact.
Ces échanges peuvent être conservés pour gérer la relation client, assurer le suivi, prouver une demande, résoudre un litige ou améliorer le service.
35. Données passagers
Le client peut fournir des informations sur les passagers : nombre de personnes, enfants, besoin de siège, bagages, particularités de prise en charge ou contraintes de mobilité. Ces données sont utilisées pour organiser correctement la prestation.
Les informations sensibles ou non nécessaires ne doivent pas être demandées sans justification. Les données de santé ne doivent pas être collectées sauf si le client fournit volontairement une information strictement nécessaire à la prise en charge.
36. Incidents, salissures, dégradations, litiges
En cas d’incident, de salissure, de dégradation, de comportement dangereux, de no-show, d’annulation litigieuse ou de réclamation, E-Motion France peut conserver les éléments nécessaires à la gestion du dossier : date, réservation, échanges, photos, constats, montants, devis, factures ou éléments de preuve.
Ces données sont distinctes de l’analytics. Elles répondent à une finalité de sécurité, preuve, responsabilité, remboursement, assurance ou litige.
37. Dashcam vidéo
Le véhicule peut être équipé d’une dashcam pour la sécurité, la prévention des incidents et la protection des personnes et des biens. Les images ne doivent pas être utilisées comme outil marketing ou de surveillance permanente des clients.
Les images peuvent être consultées uniquement en cas de nécessité : accident, agression, litige, dégradation, danger, demande d’autorité compétente ou protection des droits. La conservation doit être limitée et adaptée à l’objectif.
38. Sécurité du site
La sécurité peut nécessiter des journaux techniques : IP hashée ou tronquée, requête, horodatage, erreur, User-Agent, tentatives répétées, surcharge, payload rejeté, token invalide, session admin, accès refusé, signature webhook, validation serveur ou anomalie de formulaire.
Les logs de sécurité doivent être distincts des statistiques marketing. Ils servent à protéger le site, éviter les abus, détecter les erreurs, maintenir les flux réservation, paiement, PDF et email.
39. Prestataires techniques
Des prestataires peuvent intervenir pour l’hébergement, le nom de domaine, l’e-mail, le paiement, le géocodage, le routing, les cartes, les API de distance ou les outils techniques. Chaque prestataire reçoit uniquement les données nécessaires à son service.
Les données peuvent transiter par Stripe pour le paiement, par des providers de routing pour distances/durées, par des services d’e-mail pour confirmations ou par l’hébergeur pour le fonctionnement du site.
40. APIs d’itinéraire, géocodage, routing
Le site peut utiliser des services comme OSRM, HERE, TomTom ou Google selon les règles de configuration. Google public peut rester désactivé. Les clés API doivent rester côté serveur lorsque cela est prévu et ne doivent pas être exposées dans le JavaScript public.
Les API peuvent recevoir des adresses, coordonnées ou points de trajet nécessaires au calcul. Les résultats peuvent inclure distance, durée, péage, provider, timeout, erreur ou fallback. Pour la MAD, aucun itinéraire client complet ne doit être affiché lorsque seule une adresse d’arrivée optionnelle sert au seuil.
41. Données non vendues
E-Motion France ne vend pas les données personnelles des clients ou visiteurs. Les données ne sont pas utilisées pour du retargeting publicitaire externe dans la configuration actuelle.
Si des partenaires locaux ou dispositifs publicitaires sont envisagés plus tard, ils devront être séparés du tunnel de réservation, documentés et soumis aux règles de consentement applicables.
42. Destinataires des données
Les destinataires peuvent être E-Motion France, les administrateurs autorisés, le chauffeur concerné lorsque nécessaire, les prestataires techniques, Stripe, l’hébergeur, les services d’e-mail, les services de routing, les autorités compétentes si requis, et les conseils ou assureurs en cas de litige.
Les destinataires ne doivent recevoir que les données nécessaires à leur rôle : un prestataire de paiement n’a pas besoin des logs analytics détaillés ; un provider routing n’a pas besoin du numéro de téléphone ; un PDF client n’a pas besoin d’afficher les providers techniques internes.
43. Hébergement
Les données du site, réservations, fichiers PDF, journaux, configurations et analytics local peuvent être hébergés sur l’infrastructure utilisée par E-Motion France. Les dossiers sensibles comme le stockage analytics, les secrets, les réservations ou les sauvegardes doivent rester hors accès public direct lorsque cela est possible.
L’hébergement peut produire ses propres logs techniques. Ces logs peuvent être nécessaires à la sécurité, au diagnostic, à la disponibilité et à la preuve d’incident.
44. Durées de conservation
Les durées varient selon les catégories : réservations et facturation, données comptables, paiement, emails, litiges, analytics, logs sécurité, cookies, consentements, brouillons locaux, agrégats anonymisés. Une même personne peut donc avoir des données conservées différemment selon leur finalité.
Pour certaines solutions de mesure d’audience strictement encadrées, une durée limitée peut être appliquée aux traceurs et aux informations collectées. E-Motion France peut configurer des durées de conservation différentes selon les catégories de données : données de réservation, données comptables, données de paiement, données statistiques, données de sécurité, données de navigation, journaux techniques, données de litige et données anonymisées ou agrégées.
| Catégorie | Durée indicative | Remarque |
|---|---|---|
| Consentement cookies | 6 mois indicatifs | Peut être renouvelé ou modifié par l’utilisateur. |
| Événements analytics pseudonymisés | Jusqu’à 13 mois indicatifs | Durée configurable et purgeable. |
| Agrégats statistiques | Jusqu’à 25 mois indicatifs | Données agrégées sans identifiant direct. |
| IP complète si activée | Durée courte, par exemple 30 jours | Réglage sensible, désactivé par défaut. |
| Brouillon local formulaire | Durée courte, par exemple 7 jours | Stockage navigateur, non envoyé avant validation. |
| Réservation, preuve, facturation | Selon obligations et besoins de preuve | Peut être plus long que l’analytics. |
45. Cycle de vie des données
Le cycle de vie peut comprendre : collecte, validation, enrichissement, stockage, consultation admin, export, agrégation, anonymisation, purge, archivage de preuve ou suppression. Chaque étape doit être reliée à une finalité.
Exemple : un calcul tarifaire peut produire une estimation visible client, un détail admin, des champs cachés pour booking.json, un PDF, un email et un événement analytics. Ces sorties n’ont pas toutes la même sensibilité ni la même durée de conservation.
46. Anonymisation / pseudonymisation / agrégation
La pseudonymisation remplace un identifiant direct par un identifiant indirect, par exemple un hash IP ou une session aléatoire. Elle réduit le risque mais ne rend pas toujours la donnée totalement anonyme. L’anonymisation vise à empêcher l’identification raisonnable et doit être irréversible.
L’agrégation consiste à conserver uniquement des statistiques globales : nombre de visites, top pages, appareils, taux de calcul tarifaire, taux de succès, erreurs fréquentes. Les agrégats sont moins sensibles que les événements détaillés.
À expiration, les données peuvent être anonymisées irréversiblement ou supprimées. Les identifiants recoupables doivent être supprimés lorsque la finalité ne justifie plus leur conservation.
47. Droits des personnes
Selon les conditions applicables, une personne peut demander l’accès, la rectification, l’effacement, la limitation, l’opposition ou la portabilité de certaines données. Elle peut aussi retirer son consentement pour les traitements fondés sur celui-ci.
Pour exercer ces droits, la personne peut contacter E-Motion France à l’adresse indiquée dans cette politique. Une vérification raisonnable de l’identité peut être demandée lorsque cela est nécessaire pour éviter la communication de données à un tiers non autorisé.
48. Limites aux droits
Certains droits peuvent être limités par des obligations légales, comptables, fiscales, contractuelles, de sécurité ou de preuve. Par exemple, une réservation facturée ou liée à un litige ne peut pas toujours être supprimée immédiatement.
L’effacement d’un événement analytics pseudonymisé peut être difficile si l’identifiant n’est plus relié à une personne identifiable. Les demandes sont analysées selon la nature des données, la finalité, la durée, le niveau d’identification et les obligations applicables.
49. Retrait du consentement
Le retrait du consentement peut concerner les cookies de préférences, la mesure d’audience non essentielle, Google Analytics 4 si activé, ou d’éventuels traceurs marketing futurs. Le retrait n’affecte pas la licéité des traitements réalisés avant le retrait.
Le retrait ne désactive pas les cookies nécessaires, les traitements contractuels de réservation, les obligations légales, les preuves de paiement, les logs de sécurité indispensables ou les données nécessaires à la gestion d’un litige.
50. Gestion des préférences cookies
Le bandeau cookies permet d’accepter tout, refuser tout ou personnaliser. Les nécessaires restent toujours actifs. Les préférences, l’audience et le marketing ne doivent pas être précochés si leur consentement est requis. Les catégories sans script actif peuvent être masquées pour éviter une interface trompeuse.
Le lien global de gestion des cookies n’est pas affiché isolément dans le footer public. Les préférences peuvent être rouvertes depuis les sections dédiées aux données et cookies, notamment ici et dans les CGV.
51. Évolution de la politique
Cette politique peut évoluer lorsque le site change : nouveaux forfaits, nouvelle logique tarifaire, analytics avancé activé, nouveau provider, nouvelle page admin, nouvelle intégration, nouveau mode de paiement, nouvelles obligations ou nouvelle organisation des données.
La version et la date permettent d’identifier le document applicable. Les changements importants peuvent nécessiter une information complémentaire ou une mise à jour des choix cookies.
52. Contact
Pour toute question relative à cette politique, aux données personnelles, aux cookies, aux statistiques locales, aux journaux techniques, à une réservation ou à l’exercice de droits, le contact est : contact@e-motionfrance.fr.
La demande doit idéalement préciser l’objet, la réservation concernée si elle existe, l’adresse e-mail utilisée, la nature de la demande et les informations permettant de traiter la demande sans communiquer de données à une personne non autorisée.
Annexe A. Matrice technique des événements analytics possibles
Cette annexe détaille les événements pouvant être utilisés pour comprendre l’usage réel du site sans transformer l’analytics en système publicitaire. Les événements sont structurés, nommés et filtrés côté serveur. Les événements détaillés peuvent être conditionnés au consentement audience ou à un autre cadre applicable selon leur nature.
| Famille | Événements possibles | Données associées autorisées en mode prudent | Données sensibles à éviter |
|---|---|---|---|
| Navigation | page_viewed, page_left | page, durée, langue, appareil, navigateur, session pseudonyme | nom, téléphone, adresse exacte, commentaire libre |
| Contact | click_phone, click_whatsapp, click_reservation | type de bouton, page, mode réservation si connu | contenu de message WhatsApp, numéro complet saisi dans un formulaire |
| Cookies | cookie_choice_updated | catégories acceptées/refusées, horodatage, statut consentement | profil publicitaire ou identifiant marketing externe |
| Réservation | field_group_started, pricing_calculated, reservation_submit_clicked | groupe de champ, booléens remplis, mode Trajet/MAD | valeurs personnelles en clair avant validation |
| MAD | mad_package_selected, mad_km_pack_selected, mad_pricing_calculated | clé forfait, clé pack, devis obligatoire oui/non, prix calculé si nécessaire | adresse complète si le mode avancé n’est pas explicitement encadré |
| Trajet | trip_stop_added, trip_pricing_calculated | nombre d’étapes ou booléen, calcul réussi/échoué | coordonnées GPS précises sans autorisation ou sans nécessité |
| Erreur | pricing_error, reservation_error | type d’erreur, endpoint, page, statut technique | trace contenant secret, token, carte bancaire, mot de passe |
Annexe B. Paramètres détaillés du mode analytics avancé configurable
Le mode analytics avancé configurable est prévu pour donner à l’administration une vision plus fine du fonctionnement du site, mais il n’a pas vocation à être activé sans réflexion. Certains réglages peuvent être utiles pour résoudre un bug précis pendant une période courte ; d’autres peuvent être utiles pour comprendre les besoins commerciaux ; d’autres encore sont sensibles et nécessitent une base juridique plus stricte.
- analytics basique actif : autorise les événements minimisés de fonctionnement, pages vues et statistiques générales.
- analytics avancé actif : autorise la préparation d’événements plus riches, sous réserve des autres réglages et du consentement applicable.
- IP complète active : conserve l’adresse IP complète pendant une durée courte ; ce réglage est sensible et désactivé par défaut.
- identifiant visiteur actif : permet de relier plusieurs événements d’un même visiteur pendant une durée configurée.
- suivi clics actif : suit les clics utiles à l’ergonomie : réserver, appeler, WhatsApp, forfait, options, devis, cookies.
- suivi champs actif : suit les groupes de champs commencés sans nécessairement stocker les valeurs.
- suivi valeur champ actif : option sensible pouvant stocker une valeur ; à limiter, documenter et désactiver par défaut.
- suivi adresses sélectionnées actif : permet d’analyser les zones demandées ; sensible car une adresse peut identifier une personne.
- suivi trajets calculés actif : permet d’étudier les trajets les plus testés, distances, horaires et zones demandées.
- suivi temps passé : mesure l’ergonomie, les hésitations et les pages longues.
- suivi parcours session : reconstitue l’ordre des pages et actions importantes.
- anonymisation automatique : transforme ou supprime les données identifiantes à expiration.
- export CSV : export réservé à l’admin, à manipuler avec prudence lorsqu’il contient des données avancées.
Annexe C. Champs formulaire, pauses, hésitations et valeurs
Un champ formulaire peut être observé à plusieurs niveaux. Le premier niveau est très limité : savoir qu’un groupe a été commencé. Le second niveau indique que certains champs sont remplis ou vides. Le troisième niveau mesure la durée d’interaction, la pause, le retour en arrière, la correction, l’erreur de validation. Le quatrième niveau, plus sensible, consisterait à stocker la valeur saisie ou sélectionnée.
Les pauses dans les champs peuvent révéler un problème d’ergonomie : libellé ambigu, champ trop long, adresse non trouvée, date difficile à choisir, mode de paiement mal compris, forfait MAD peu clair, option supplémentaire mal comprise, CGV non visibles, bouton trop bas en mobile, message d’erreur imprécis. Ces informations peuvent améliorer le site sans nécessiter le stockage du contenu personnel complet.
Les valeurs de champ, lorsqu’elles sont activées, doivent être limitées. Exemple : une adresse sélectionnée peut être utile pour analyser les zones demandées, mais elle peut aussi révéler un domicile, un lieu de travail, un établissement de santé, une gare ou un hôtel. Une valeur de commentaire libre peut contenir des données sensibles ou personnelles non prévues. Pour cette raison, la collecte de valeurs libres doit rester désactivée par défaut.
Annexe D. Adresses sélectionnées, autocomplete et trajets recherchés
Les données d’autocomplétion peuvent inclure la chaîne recherchée, la suggestion sélectionnée, une ville, un code postal, un pays, des coordonnées approximatives, un identifiant de lieu ou une catégorie de POI. Une adresse sélectionnée peut aider à comprendre les départs les plus demandés, les destinations fréquentes, les zones mal desservies, les trajets récurrents, les seuils de devis et les besoins de forfaits.
Ces informations sont utiles pour adapter les zones desservies, les prix, les forfaits, les textes, les disponibilités, les partenariats locaux, les options de mise à disposition et les règles de seuil. Elles peuvent aussi détecter des erreurs : mauvaise suggestion, ville incorrecte, champ GPS inutilisable, absence de résultat, incohérence entre départ et arrivée, destination très éloignée en MAD.
Pour limiter les risques, plusieurs niveaux existent : ne rien stocker ; stocker seulement un booléen adresse sélectionnée ; stocker seulement la ville ; stocker une zone approximative ; stocker un code postal tronqué ; stocker la distance approximative ; stocker l’adresse complète uniquement en mode avancé explicitement activé et documenté.
Annexe E. Journaux techniques et exemples de contenus acceptables
Un journal technique acceptable peut indiquer qu’un endpoint a répondu 400, qu’un payload était trop gros, qu’un événement analytics détaillé a été rejeté faute de consentement audience, qu’un PDF n’a pas pu être créé, qu’une session Stripe n’a pas été créée faute de CGV acceptées, qu’un calcul OSRM a échoué, ou qu’un fichier JSON était invalide.
Un journal technique ne doit pas contenir de secret API, clé Stripe, token webhook, mot de passe admin, numéro de carte bancaire, CVC, données Stripe sensibles, commentaire libre complet, données de santé, ou contenu personnel inutile. Si une erreur contient trop d’information, elle doit être réduite avant stockage ou affichage.
- Acceptable : `pricing_error`, type `osrm_unreachable`, page `/reservation/index.html`, mode `MAD`.
- Acceptable : `reservation_error`, type `cgv_required`, source `public_form`.
- Acceptable : `field_group_started`, groupe `paiement`, sans valeur du champ.
- À éviter : commentaire libre complet avant réservation validée.
- À exclure : numéro de carte, secret Stripe, token API, mot de passe.
Annexe F. Conservation, purge et anonymisation opérationnelle
La conservation ne doit pas être comprise comme une durée unique. Une donnée de réservation peut être conservée pour la preuve et la facturation, alors qu’un événement analytics détaillé doit être purgé ou anonymisé plus rapidement. Une IP complète, lorsqu’elle existe, doit avoir une durée plus courte qu’un agrégat statistique. Un agrégat sans identifiant peut être utile plus longtemps qu’un événement brut.
La purge peut supprimer les fichiers expirés. L’anonymisation peut supprimer les identifiants de session, IP, User-Agent détaillé, referrer précis ou tout élément recoupable. L’agrégation peut conserver seulement des volumes : visites par jour, pages vues, appareils, langues, taux de calcul, taux d’abandon, erreurs fréquentes. La reconstruction d’agrégats permet de recalculer des statistiques à partir d’événements encore conservés.
Un bon cycle opérationnel peut être : événements bruts actifs pendant une durée courte ou moyenne ; anonymisation automatique à expiration ; conservation agrégée plus longue ; suppression définitive lorsque l’objectif n’existe plus ; export admin limité ; contrôle régulier des catégories activées ; documentation dans l’inventaire cookies/traceurs.
Annexe G. Accès admin, export et responsabilité interne
Les données avancées, lorsqu’elles existent, doivent rester visibles uniquement dans l’administration. L’admin peut consulter des tableaux, derniers événements, statistiques de pages, sources, appareils, navigateurs, pays, modes de réservation, paiements choisis, erreurs et abandons. Un export CSV peut être utile, mais il augmente le risque de diffusion accidentelle et doit être réservé à un usage ponctuel.
L’administration doit distinguer données opérationnelles et données statistiques. Une réservation validée contient des données client nécessaires au service. Un événement analytics avant validation doit rester minimisé. Un log sécurité répond à la protection du site. Un export de statistiques sert à l’amélioration. Ces finalités ne doivent pas être mélangées sans nécessité.
Les accès admin doivent rester protégés, et aucune donnée avancée ne doit être exposée dans une page publique, un JSON public, un JavaScript public, un rapport public ou un PDF client si elle n’est pas utile au client.