Politique de confidentialité — directtransfer.ch

0À propos de ce document

Ceci est la Politique de confidentialité du site institutionnel directtransfer.ch et des applications DirectTransfer (passager et chauffeur), exploitées par la plateforme, y compris le module Cargo B2B. Elle décrit quelles données personnelles nous traitons, à quelle fin, sur quelle base légale, avec qui nous les partageons, pendant combien de temps nous les conservons, et quels sont vos droits en vertu de la Loi fédérale suisse sur la protection des données (LPD).

Note de traduction : les articles de la Loi fédérale suisse sur la protection des données (*Loi sur la protection des données*, LPD ; en allemand *Datenschutzgesetz*, DSG/nDSG ; en anglais *Federal Act on Data Protection*, FADP) cités ci-dessous se fondent sur la version française consolidée publiée par la Confédération sur Fedlex (RS 235.1), état au 2025-07-07. La version qui fait foi pour l'espace francophone est toujours le texte légal français (LPD) lui-même ; là où cette politique utilise en complément le sigle anglais « FADP », c'est uniquement par cohérence avec le document source portugais de cette politique.

1Qui nous sommes et ce que couvre ce document

DirectTransfer est exploitée par la plateforme (« nous », « la plateforme », « DirectTransfer »), responsable du traitement de données personnelles au sens de l'art. 5 let. j LPD pour les finalités décrites dans cette politique.

Identité : DirectTransfer, une plateforme de transport basée en Suisse. État de mise en œuvre, avec précision : la raison sociale, le siège enregistré et le numéro d'immatriculation au registre du commerce (IDE) ne sont pas publiés dans cette politique tant qu'aucune inscription officielle et vérifiable au registre du commerce suisse (Zefix/IDE) n'existe — aucune attribution à une personne morale non confirmée n'est faite nulle part dans ce document.
Contact pour les questions de confidentialité : privacidade@directtransfer.ch.
Autorité de surveillance compétente : Préposé fédéral à la protection des données et à la transparence (PFPDT), conformément à l'art. 4 LPD.

Cette politique s'applique au site directtransfer.ch, à l'application passager, à l'application chauffeur et au module Cargo B2B, chaque fois que nous traitons des données personnelles d'une personne concernée au sens de l'art. 5 let. b LPD.

1.1Ce qu'est DirectTransfer, et ce qu'elle n'est pas — réaffirmation obligatoire

Cette clause est réaffirmée parce qu'elle conditionne directement la manière dont nous traitons vos données : DirectTransfer est un logiciel en tant que service (SaaS). la plateforme n'emploie jamais le chauffeur — il n'existe aucun lien de subordination salariale ; le chauffeur est responsable de son propre véhicule, de son assurance et de son horaire. La plateforme ne fixe jamais le prix de la course — le chauffeur détermine le montant à l'intérieur d'une fourchette simplement suggérée, dans le cadre d'un mécanisme d'enchère/négociation bilatérale. La plateforme n'intermédie jamais financièrement la course — le paiement de la course est intégralement pair-à-pair (P2P) entre passager et chauffeur, par TWINT, SumUp, espèces ou carte propre du chauffeur ; aucune donnée de paiement de course n'est traitée ni stockée par DirectTransfer. Ceci est distinct et séparé du paiement de l'abonnement mensuel du chauffeur à la plateforme (section 4.9), qui constitue un flux de données différent. Cette distinction détermine, entre autres, quelles données de paiement existent dans notre système et lesquelles n'existeront jamais.

2Définitions pertinentes (art. 5 LPD)

Nous utilisons les termes de la loi tels que définis à son art. 5 :

Données personnelles : toutes les informations concernant une personne physique identifiée ou identifiable (art. 5 let. a).
Personne concernée : la personne physique dont les données personnelles font l'objet d'un traitement (art. 5 let. b).
Données personnelles sensibles : comprennent notamment les données biométriques identifiant une personne physique de manière univoque, ainsi que les données sur des poursuites ou sanctions pénales et administratives (art. 5 let. c, ch. 4 et 5). Note appliquée à notre cas concret : la pièce d'identité et le permis de conduire soumis par le chauffeur lors de l'inscription, ainsi que les données biométriques qui en sont extraites par le prestataire tiers de vérification d'identité (KYC/IDV), constituent des données personnelles sensibles au sens du ch. 4 — elles ne sont pas traitées comme des données personnelles ordinaires, voir section 7. L'extrait de casier judiciaire du chauffeur, exigé dans certains cantons, constitue une donnée personnelle sensible au sens du ch. 5 (données sur des poursuites ou sanctions pénales et administratives) — voir sections 4.2 et 6.
Traitement : toute opération relative à des données personnelles — collecte, enregistrement, conservation, utilisation, modification, communication, archivage, effacement ou destruction (art. 5 let. d).
Violation de la sécurité des données : toute violation de la sécurité entraînant de manière accidentelle ou illicite la perte de données personnelles, leur effacement, leur destruction, leur modification, ou l'accès à ces données ou leur communication par des personnes non autorisées (art. 5 let. h).
Responsable du traitement : quiconque détermine, seul ou conjointement, les finalités et les moyens du traitement — la plateforme, pour les finalités décrites ici (art. 5 let. j).
Sous-traitant : quiconque traite des données personnelles pour le compte du responsable du traitement — par exemple, le prestataire d'infrastructure de stockage d'images, ou le prestataire de vérification documentaire (art. 5 let. k).

3Principes que nous appliquons (art. 6 LPD)

Tout traitement décrit dans cette politique suit les principes de l'art. 6 LPD : licéité (§1) ; bonne foi et proportionnalité (§2) ; collecte uniquement dans un but déterminé et reconnaissable pour la personne concernée, sans traitement ultérieur incompatible avec ce but (§3) ; destruction ou anonymisation des données dès qu'elles ne sont plus nécessaires au regard du but du traitement (§4) ; exactitude des données, avec rectification ou effacement de ce qui est inexact ou incomplet (§5). Lorsque nous requérons votre consentement, celui-ci n'est valable que s'il est donné librement, pour un ou plusieurs traitements déterminés, après une information adéquate (§6) ; et il est expressément exigé pour le traitement de données personnelles sensibles (§7 let. a).

Note méthodologique sur la citation de la base légale dans cette politique : la LPD ne comporte pas de liste énumérée de « bases légales » à la manière de l'art. 6(1) du RGPD. Le régime suisse est le suivant : le traitement est licite s'il respecte les principes de cet art. 6 (licéité, proportionnalité, finalité) et ne porte pas atteinte aux droits de la personnalité de la personne concernée (art. 30) ; en cas d'atteinte potentielle à la personnalité, le traitement nécessite un motif justificatif propre relevant de l'art. 31, typiquement la « conclusion ou l'exécution d'un contrat » selon l'art. 31 §2 al. a (voir application directe à la section 13). Pour cette raison, chaque sous-section de la section 4 ci-dessous ancre la licéité générale dans l'art. 6 et n'invoque l'art. 31 §2 al. a que lorsqu'il existe une justification effective d'une atteinte potentielle à la personnalité découlant de l'exécution d'un contrat ; à partir de cette section, chaque sous-section invoquant ce motif le fait par renvoi bref (« motif justificatif : art. 31 §2 al. a, selon le critère déjà établi à la présente section 3 »), sans répéter le paragraphe explicatif complet. Les art. 16-17 LPD concernent exclusivement le transfert international de données (communication de données personnelles à l'étranger) et ne sont cités qu'à la section 8, jamais comme base légale générale pour le traitement domestique.

Note de traduction sur « motif justificatif » : le document source portugais utilise le terme « fundamento de justificação », concept propre au régime de la LPD selon l'art. 31, sans équivalent direct dans le vocabulaire du RGPD. Le terme « motif justificatif » (art. 31 LPD) est employé ici délibérément comme terme juridique effectif de la version française de la LPD, et ne doit pas être assimilé au terme « base légale » du RGPD, qui porte une connotation différente, comme expliqué dans cette section.

Note de vérification de la source, concernant « art. 31 §2 al. a » : l'existence du motif justificatif d'exécution de contrat à l'art. 31 §2 est confirmée par la source primaire consultée (le registre des sources primaires de la LPD tenu en interne pour cette politique, Partie A, « Art. 30-31 »), mais cette source résume/paraphrase le contenu de l'article — contrairement aux art. 5, 6, 8, 19 et 25, qui sont des copies littérales (verbatim) extraites via pdftotext du PDF officiel Fedlex — sans citer le texte intégral et numéroté des lettres de l'art. 31 §2. La référence à la lettre exacte « al. a » dans cette politique constitue donc la lecture la plus probable, cohérente avec la structure typique de ce type de norme, et non une citation vérifiée mot pour mot de la lettre. La substance du motif (exécution du contrat comme motif justificatif d'une atteinte potentielle à la personnalité) est utilisée dans cette politique avec un niveau de confiance élevé ; la lettre exacte de l'alinéa reste à un niveau de confiance moyen, sous réserve de confirmation directe par rapport au texte intégral de l'art. 31 ou d'un avis d'un avocat suisse licencié — le même standard de précaution déjà appliqué à l'art. 9 (voir le registre juridique interne détaillé tenu à cet effet).

4Quelles données nous collectons et pourquoi

4.1Inscription du compte

Nom, coordonnées (téléphone, e-mail) du passager et du chauffeur, lors de la création du compte. Finalité : fournir le service d'intermédiation technologique entre passager et chauffeur. Base légale : licéité, proportionnalité et finalité reconnaissable du traitement (art. 6 §1-3) — les données sont collectées dans le but spécifique et reconnaissable pour la personne concernée de créer et d'exploiter le compte ; motif justificatif : art. 31 §2 al. a, selon le critère déjà établi à la section 3.

4.2Vérification documentaire du chauffeur — données sensibles

Lors de l'inscription du chauffeur, nous collectons une pièce d'identité, un permis de conduire et, selon le canton et la catégorie, d'autres autorisations (par ex. carte de taxi, carte de limousine). Là où le canton l'exige — par exemple Zurich et Bâle, selon une recherche réglementaire cantonale interne déjà disponible pour le projet — nous collectons également l'extrait de casier judiciaire du chauffeur, d'une validité inférieure à 3 mois au moment de la soumission. Ces documents sont soumis par photo, selon le flux décrit dans le module d'Inscription du chauffeur, et traités en deux couches :

Couche 1 — prestataire tiers (KYC/IDV) : confirme l'authenticité du document et en extrait les champs lisibles (nom, numéro, dates, type de document), y compris, le cas échéant, une vérification biométrique. Ce traitement porte sur des données personnelles sensibles au sens de l'art. 5 let. c ch. 4 (pièce d'identité, permis de conduire, données biométriques) et, le cas échéant pour l'extrait de casier judiciaire, ch. 5 (données sur des poursuites ou sanctions pénales et administratives) — exigeant votre consentement explicite (art. 6 §7 al. a) au moment de la soumission du document, ainsi qu'un contrat de traitement de données avec le prestataire. Cette obligation découle du traitement de données personnelles par un sous-traitant pour le compte du responsable — l'art. 5 let. k LPD définit le sous-traitant en ces termes — et s'inscrit dans les principes généraux de licéité et de proportionnalité de l'art. 6 ainsi que dans le devoir de sécurité de l'art. 8. Cette politique ne cite pas ici de numéro d'article spécifique de la LPD relatif à la sous-traitance au-delà de la définition de l'art. 5 let. k, celle-ci n'ayant pas été confirmée par rapport au texte intégral de la loi.
Couche 2 — moteur de règles interne, sans intelligence artificielle : vérifie si les champs extraits satisfont à l'exigence documentaire du canton et de la catégorie déclarés. N'utilise aucun modèle d'IA/ML ; il s'agit d'une comparaison déterministe par rapport à une table de configuration.

Un verdict incertain à l'une ou l'autre couche n'est jamais auto-approuvé ni auto-rejeté — il fait toujours l'objet d'un examen humain par un administrateur. Les documents du chauffeur, y compris l'extrait de casier judiciaire, sont accessibles uniquement au chauffeur lui-même et aux administrateurs, jamais au passager, avec le même traitement renforcé (consentement explicite, RBAC restreint) décrit à la section 6.

Renouvellement et vérification continue : l'exigence minimale appliquée est une validité inférieure à 3 mois de l'extrait de casier judiciaire au moment de chaque soumission ; la soumission initiale ne doit pas être interprétée comme couvrant l'intégralité du cycle de vie du chauffeur. La fréquence de renouvellement exigée et le mécanisme de vérification continue des antécédents, le cas échéant selon le canton, sont communiqués directement au chauffeur via le canal de contact de l'application, et seront publiés dans cette section dès que la politique opérationnelle correspondante sera finalisée.

Prestataire tiers (KYC/IDV) : le nom commercial du prestataire sera publié dans cette section dès que la sélection sera finalisée, selon le processus de mise en concurrence en cours ; disponible entre-temps sur demande via le canal de contact de la section 15. Le contrat de traitement de données avec ce prestataire, mentionné ci-dessus, et l'évaluation du transfert international (section 8), si le prestataire n'opère pas sur le territoire suisse ou de l'UE/EEE, seront conclus et publiés en même temps que cette identification, avant que toute soumission de document ne soit traitée par ce prestataire en production.

4.3Localisation en temps réel pendant la course

La position approximative des véhicules disponibles est communiquée au passager avant l'acceptation d'une course ; après acceptation, la position du chauffeur est communiquée au passager jusqu'à l'embarquement. Finalité : exécution directe du contrat de transport convenu entre passager et chauffeur. Base légale : proportionnalité et finalité reconnaissable pour la personne concernée au moment de la demande (art. 6 §2-3), la course pouvant porter atteinte à la personnalité de la personne concernée par l'exposition de sa position géographique à un tiers ; motif justificatif : art. 31 §2 al. a, selon le critère déjà établi à la section 3.

4.4Photo du lieu de prise en charge — suppression automatique sous 24 heures

Pendant la communication de la course, une photo du lieu de prise en charge peut être partagée entre passager et chauffeur, stockée sur Cloudflare R2.

La conception du cycle de vie déjà figée du projet prévoit la suppression automatique de cette photo 24 heures après le téléversement, et aucune conservation au-delà de ce délai pour une quelconque finalité secondaire — selon la conception interne du schéma de données du projet, qui fixe cette fenêtre de 24 h comme dérivée au moment de la requête (created_at + interval '24 hours') pour les messages de type photo. État de mise en œuvre, avec précision : le service backend de la plateforme existe et fonctionne pour l'inscription du chauffeur, mais le module course/chat qui exécuterait cette fenêtre — un job applicatif de purge et/ou une règle de cycle de vie du bucket Cloudflare R2 — n'a pas encore été construit ; et, s'agissant de la couche base de données, la ratification finale de la politique de sécurité correspondante au niveau de la base de données par la revue de sécurité interne de la plateforme demeure en attente. Jusqu'à ce que ce module soit construit et cette ratification achevée, les 24 heures décrites ici constituent la conception contraignante du projet, pas encore un fait opérationnel vérifiable en production.

Finalité : faciliter la rencontre physique entre les parties. Base légale : exécution du contrat et proportionnalité (art. 6 §2-3) ; la suppression automatique sous 24 heures conçue ci-dessus est l'application concrète du devoir de destruction de l'art. 6 §4 dès que la donnée n'est plus nécessaire à la finalité — la rencontre a déjà eu lieu ; motif justificatif : art. 31 §2 al. a, selon le critère déjà établi à la section 3.

4.5Messages du chat de la course (`ride_messages`)

Pendant une course active, passager et chauffeur peuvent échanger des messages prédéfinis, du texte libre limité (jusqu'à 100 caractères) ou une photo, via le chat de la course. Finalité : communication directe entre les parties pendant la course active — par exemple instructions d'embarquement, ajustement du point de rencontre — pendant le déroulement de la course.

Conservation : la règle de cycle de vie conçue est la suppression effective (hard delete) du contenu du chat à la clôture de la course — une décision de conception déjà arrêtée du projet quant au critère, non une lacune. Selon la revue de sécurité et de conformité interne de la plateforme, il s'agit de l'application directe du commandement « Zéro chat après la fin de la course », et cette règle est explicitement inscrite dans la conception interne du schéma de données du projet. État de mise en œuvre, avec précision : cette conception de schéma attribue expressément le job de purge au service backend de la plateforme ; ce service backend existe désormais et fonctionne pour l'inscription du chauffeur, mais le module course/chat qui exécuterait ce job de purge spécifique n'a pas encore été construit ; la politique de sécurité correspondante au niveau de la base de données demeure consignée uniquement dans un document de travail interne, explicitement marquée « STUB, NON RATIFIÉ », en attente de ratification finale par la revue de sécurité interne de la plateforme. Jusqu'à ce que ce module soit construit et cette ratification achevée, la suppression effective (hard delete, non un soft-delete, sans marquage « supprimé ») constitue la conception contraignante du projet, pas encore un fait opérationnel vérifiable en production.

Base légale : exécution du contrat de transport entre les parties et sécurité de la coordination de la course en cours (art. 6 §2-3) ; la suppression automatique à la clôture de la course, conçue ci-dessus, est l'application concrète du devoir de destruction de l'art. 6 §4 dès que la donnée n'est plus nécessaire à la finalité — la course est déjà terminée ; motif justificatif : art. 31 §2 al. a, selon le critère déjà établi à la section 3.

Aucun message de chat n'est lu, modéré ou conservé par DirectTransfer au-delà de ce qui est nécessaire au fonctionnement technique en temps réel de la course elle-même ; toute lecture ponctuelle par un administrateur dans le cadre de l'instruction d'une plainte formelle suit le même schéma d'accès privilégié audité décrit à la section 12.

Métadonnées de signalement d'abus — en cours d'évaluation, non implémentées : un enregistrement minimal de métadonnées de signalement d'abus (et non le contenu du message) est en cours d'évaluation, sous réserve d'une citation juridique avant toute mise en œuvre, selon la revue de sécurité et de conformité interne de la plateforme ; en cas de mise en œuvre, cette section sera mise à jour.

4.6Communication par appel téléphonique — appel GSM natif, sans VoIP

La plateforme met à disposition un bouton d'appel qui utilise la fonction d'appel GSM native du téléphone mobile de chaque utilisateur. Il n'existe aucun système de VoIP, de WebRTC, ni d'intermédiation d'appel par DirectTransfer — l'appel transite entièrement par le réseau de l'opérateur mobile de chaque partie, en dehors de notre infrastructure.

Information pertinente pour votre consentement éclairé : en utilisant ce bouton, le numéro de téléphone de chaque partie peut devenir visible pour l'autre partie au moment de l'appel, parce que le réseau GSM natif transmet le numéro d'origine/destination réel aux deux parties de par la nature même du protocole — cette exposition ne peut être évitée tout en conservant le bouton d'appel natif, selon l'évaluation technique consignée par la revue de sécurité et de conformité interne de la plateforme.

Ce qui n'existe pas : aucun numéro-relais réseau ne remplace votre numéro réel pendant l'appel — il n'existe aucun véritable proxy/relais téléphonique ; entre autres raisons, un relais de ce type entrerait en collision avec le veto « Zéro VoIP » déjà fixé pour ce produit.

Ce qui existe : l'application n'affiche jamais votre numéro, ni celui de l'autre partie, sous forme de texte sur aucun écran des applications passenger ou driver — le numéro n'apparaît que sous forme de bouton d'action ; et l'application demande une confirmation explicite avant de déclencher le composeur natif (un avertissement indiquant que le numéro deviendra visible pour l'autre partie en cas de poursuite). Ces deux mesures d'atténuation constituent le comportement par défaut des applications.

Note sur la suppression de l'identification de l'appelant (CLIR) : lorsqu'elle est disponible, la suppression du numéro d'origine par un code réseau natif (par ex. préfixe #31#/*31#) dépend entièrement de l'opérateur téléphonique de chaque utilisateur — la plateforme ne vérifie, n'impose ni ne garantit cette suppression avant de déclencher le composeur natif. Ce n'est pas une mesure d'atténuation garantie par le produit ; elle est enregistrée comme un élément d'étude de faisabilité par opérateur, non encore conclue, selon la revue de sécurité et de conformité interne de la plateforme.

Note secondaire : le masquage d'écran décrit ci-dessus ne couvre pas le back-office admin, qui dispose déjà d'un accès en lecture en texte clair au numéro de téléphone via le RBAC de la table users (sections 6 et 12), à des fins de support — cet accès privilégié génère obligatoirement un enregistrement d'audit (qui, quand, pourquoi) ; il ne constitue pas une exception silencieuse à la mesure d'atténuation d'écran.

Nous n'enregistrons, ne stockons et n'avons accès à aucun contenu de cet appel, car il ne transite jamais par notre infrastructure.

Base légale : le devoir d'information et de transparence de l'art. 19 §2 al. c LPD, qui exige d'informer la personne concernée, au moment de la collecte des données, sur « les destinataires ou les catégories de destinataires auxquels des données personnelles sont communiquées » (texte littéral, selon le registre des sources primaires tenu en interne pour cette politique, Partie A) — il s'agit de l'ancrage spécifique correct pour ce scénario, identifié par la revue de sécurité et de conformité interne de la plateforme : l'autre partie à la course est la destinataire à laquelle le numéro de téléphone devient visible au moment de l'appel, ce qui constitue précisément une communication à un destinataire, et non l'extension générique du §1 du même article (informer sur des données non collectées auprès de la personne concernée elle-même) utilisée dans une version antérieure de ce texte ; cette exposition est portée à la connaissance de l'utilisateur à l'avance par cette clause — ainsi que la proportionnalité du traitement (art. 6 §2), dans le but de permettre la rencontre physique et la communication pendant la course. Motif justificatif de la communication elle-même : art. 31 §2 al. a, selon le critère déjà établi à la section 3 — ce motif n'est pas affecté par le réancrage ci-dessus, qui ne porte que sur la composante du devoir d'information/transparence. Ce devoir d'information est rempli par l'information explicite ci-dessus et par le dialogue de confirmation obligatoire avant le déclenchement du composeur natif. Il s'agit de la base légale présentée par cette politique pour cette clause — voir l'état de confirmation dans le paragraphe suivant.

État de mise en œuvre, avec la même rigueur de précision utilisée dans le reste de cette politique : le comportement décrit ci-dessus (masquage d'écran, dialogue de confirmation) constitue la conception contraignante déjà figée du produit pour les applications passenger et driver. Le blocage de l'activation de ce flux en production, selon la revue de sécurité et de conformité interne de la plateforme, ne dépend pas du service backend de la plateforme (ce flux, contrairement à ceux des sections 4.4, 4.5, 4.7, 6 et 12, ne transite jamais par notre infrastructure, comme décrit ci-dessus) — il dépend de la confirmation de la suffisance juridique par la revue de sécurité et de conformité interne de la plateforme quant à savoir si l'ancrage sur l'art. 19 §2 al. c + art. 6 §2 ci-dessus couvre adéquatement, en termes de proportionnalité, ce scénario spécifique. Le réancrage de la citation sur l'art. 19 §2 al. c, appliqué ci-dessus, corrige l'ancrage précédemment décrit comme incertain dans cette politique : l'exposition du numéro de téléphone d'une partie à l'autre partie pendant l'appel constitue une communication à un destinataire au moment de l'appel, et c'est exactement ce scénario — le devoir d'informer sur « les destinataires... auxquels des données personnelles sont communiquées » — que l'art. 19 §2 al. c couvre dans son texte littéral, et non plus l'extension générique du §1 (informer sur des données non collectées auprès de la personne concernée elle-même) utilisée dans une version antérieure de ce texte. Cette politique présente l'art. 19 §2 al. c + art. 6 §2 comme fondement de la communication déjà faite ci-dessus ; la suffisance de cet ancrage au regard du test de proportionnalité de l'art. 6 §2 dans ce scénario concret — par exemple, si l'absence d'option de refus de la fonctionnalité ou de garantie de CLIR affecte cette suffisance — demeure une confirmation technico-juridique de la revue de sécurité et de conformité interne de la plateforme, et non un fait déjà arrêté par la seule équipe juridique interne. Note de coordination entre documents : cette position est celle de cette Politique de confidentialité en particulier ; la clause parallèle sur le même sujet dans les Conditions d'utilisation suit son propre cycle de mise à jour et demeure marquée dans ce document comme en attente de citation — les deux documents ne convergent pas encore, et cette note évite de laisser croire qu'ils convergent déjà.

4.7Historique de course et identifiant anonymisé (modèle en deux phases)

Par course, nous enregistrons : l'origine et la destination (coordonnées et adresse textuelle), l'horodatage de début et de fin, la catégorie de véhicule, le montant déclaré par le chauffeur, le statut final de la course, ainsi qu'un identifiant de passager et de chauffeur. Aucune autre donnée n'est enregistrée par défaut.

Cet identifiant fonctionne selon deux phases distinctes, non une seule phase :

1. Pendant la course active : l'identifiant est résoluble (référence directe à l'enregistrement de l'utilisateur), nécessaire aux fonctionnalités en temps réel — contrôle d'accès par ligne (RLS), connexion en temps réel (Socket.io) et chat de la course en cours (section 4.5).

2. Lors de la transition vers l'historique, à la fin de la course, l'identifiant est converti en un hachage cryptographique irréversible et salé (par ex. SHA-256), sans clé étrangère permettant de retrouver l'identité de l'utilisateur à partir de l'enregistrement historique.

La règle par défaut telle que conçue, selon le Commandement 5 (Row Level Security) et les exigences RLS déjà spécifiées par la revue de sécurité et de conformité interne de la plateforme, consiste en une non-identification nominale réciproque entre les parties : ni le passager ne doit voir le nom du chauffeur, ni le chauffeur le nom du passager, sur aucun écran, y compris l'historique. État de mise en œuvre, avec précision : cette règle est conçue et reflétée dans le modèle en deux phases décrit ci-dessus (identifiant résoluble pendant la course, hachage irréversible lors de la transition vers l'historique), mais le mécanisme exécutable d'application — politiques de sécurité concrètes au niveau de la base de données et couche de masquage de colonne empêchant la fuite d'identité même lorsque la ligne est visible — dépend de la ratification technique finale par la revue de sécurité interne de la plateforme et du module course/historique du service backend de la plateforme, qui n'a pas encore été construit (le service backend ne couvre aujourd'hui que l'inscription du chauffeur) ; la politique de sécurité correspondante au niveau de la base de données demeure marquée « STUB, NON RATIFIÉ » dans le document de travail interne. Cette section n'affirme pas la non-identification nominale comme un fait opérationnel déjà actif en production, seulement comme une règle de conception déjà figée, en attente d'une application technique ratifiée.

Identification pour motif de sécurité — en cours d'évaluation, non décidée : il est encore à l'étude de savoir si, pour des motifs de sécurité, une identification ponctuelle entre chauffeur et passager (ou inversement) pourrait s'avérer nécessaire, ce qui créerait une tension avec la règle générale de non-identification nominale déjà figée ci-dessus — selon la documentation produit interne du projet relative à l'historique de course. Cette politique n'affirme, dans cette version, ni l'identification ni son absence totale en tant qu'exception de sécurité — elle affirme uniquement la règle générale de non-identification réciproque déjà figée, applicable tant que cette évaluation n'est pas terminée. Toute résolution future de ce point est consignée dans cette section et confirmée par la revue de sécurité interne de la plateforme comme compatible, ou non, avec la RLS déjà figée, sans réouverture informelle.

Base légale de l'anonymisation : la transition vers l'historique est l'application directe du devoir de l'art. 6 §4 — la donnée est anonymisée dès qu'elle n'est plus nécessaire, sous forme identifiable, à la finalité d'exploitation de la course en cours.

4.8Évaluation de la plateforme (0 à 5 étoiles)

À la fin de chaque course, le passager peut évaluer la plateforme, non le chauffeur individuellement. Cette note est liée à l'identifiant anonymisé du passager et à l'événement de course, à des fins de mesure produit de l'entreprise. Elle n'est jamais agrégée, affichée ou consultable par identifiant de chauffeur, n'apparaît jamais sur un écran ou une API accessible au chauffeur, et n'est jamais utilisée pour attribuer une course. Base légale : intérêt légitime et proportionné à mesurer la satisfaction à l'égard du service fourni par la plateforme (art. 6 §2), sans finalité de gestion ou d'évaluation de la performance individuelle du chauffeur — cette distinction de finalité est précisément la raison pour laquelle cette note ne circule pas vers le chauffeur.

4.9Paiements — course (P2P) et abonnement (Stripe), flux séparés

Conformément au renvoi de la section 1.1 : le paiement de la course est intégralement pair-à-pair, en dehors de notre infrastructure, et nous ne traitons ni ne stockons aucune donnée de paiement de la course. Le seul flux de paiement que nous traitons est l'abonnement mensuel du chauffeur à la plateforme, via le prestataire de paiement Stripe (Stripe Billing), qui traite directement les données de facturation et de carte du chauffeur, selon les propres conditions et politique de confidentialité de Stripe. Base légale : proportionnalité et finalité du traitement (art. 6 §2-3), exécution du contrat d'abonnement entre le chauffeur et la plateforme ; motif justificatif : art. 31 §2 al. a, selon le critère déjà établi à la section 3.

4.10Module Cargo B2B et flux potentiellement transfrontaliers

Le module Cargo B2B peut impliquer des clients et des transporteurs situés dans l'Union européenne. Voir la section 10 sur le régime juridique applicable à ce cas.

4.11Site institutionnel, cookies et analytique

L'inventaire final des cookies et technologies de suivi du site institutionnel directtransfer.ch sera publié dans cette section, avec renvoi à une politique de cookies dédiée si la complexité le justifie, avant l'activation de tout cookie qui n'est pas strictement nécessaire au fonctionnement technique du site. Jusqu'à cette publication, le site institutionnel n'active aucun cookie analytique ou marketing de tiers sans que cet inventaire soit d'abord décrit ici et, le cas échéant, sans le consentement préalable exigé par l'art. 6 §6-7 LPD.

4.12Sécurité, prévention de la fraude et conformité légale

Nous pouvons traiter des données personnelles pour détecter et prévenir la fraude, et pour nous conformer à une obligation légale ou répondre à une demande légitime d'une autorité compétente. Base légale : licéité et proportionnalité du traitement (art. 6 §1-2), inscrites dans le cadre du respect d'une obligation légale à laquelle la plateforme est soumise. Lorsque ce traitement constitue une atteinte potentielle à la personnalité de la personne concernée, le motif justificatif applicable découle de l'art. 31 §2, dans ses lettres relatives au respect d'une obligation légale ou à la sauvegarde d'un intérêt prépondérant — catégories générales de la norme, distinctes de la let. a (exécution de contrat) utilisée dans d'autres sous-sections de cette politique ; la lettre exacte applicable à chaque situation concrète est déterminée au cas par cas au moment du traitement.

5Base légale, en synthèse

Nous traitons vos données personnelles sur la base, selon le cas : de votre consentement explicite, requis en particulier pour les données sensibles (art. 6 §6-7 al. a) ; de l'exécution du contrat d'utilisation de la plateforme ou du contrat de transport entre vous et l'autre partie à la course, motif justificatif de l'art. 31 §2 al. a lorsqu'il existe une atteinte potentielle à la personnalité ; du respect d'une obligation légale à laquelle la plateforme est soumise ; et de l'intérêt légitime, toujours soumis au test de proportionnalité de l'art. 6 §2. Lorsqu'une finalité spécifique exige un consentement explicite supplémentaire (par ex. donnée sensible de document du chauffeur, section 4.2), nous sollicitons ce consentement séparément, avec un enregistrement d'audit selon la section 16.

6Données personnelles sensibles — traitement renforcé

En rappel de la section 4.2 : la pièce d'identité, le permis de conduire et la donnée biométrique associée du chauffeur constituent des données personnelles sensibles (art. 5 let. c ch. 4). L'extrait de casier judiciaire du chauffeur, exigé dans certains cantons — par exemple Zurich et Bâle, selon une recherche réglementaire cantonale interne déjà disponible pour le projet — constitue également une donnée personnelle sensible, relevant du ch. 5 du même article (données sur des poursuites ou sanctions pénales et administratives), et reçoit le même traitement renforcé ci-dessous. Nous appliquons, aux deux catégories, selon la conception déjà figée du projet : (i) consentement explicite au moment de la soumission (art. 6 §7 al. a) ; (ii) accès restreint conçu par contrôle d'accès par rôle (RBAC) — seuls le chauffeur lui-même et les administrateurs, jamais le passager, y compris pour l'extrait de casier judiciaire, selon la matrice RBAC déjà spécifiée par la revue de sécurité et de conformité interne de la plateforme — le contrôle RBAC lui-même est construit, testé et opérationnel dans le service backend de la plateforme pour l'accès aux documents du chauffeur ; la sécurité au niveau des lignes de la base de données (RLS) sur les données sous-jacentes, en tant que seconde couche d'application complémentaire décrite à la section 4.7 ci-dessus, demeure en attente de ratification finale par la revue de sécurité interne de la plateforme et reste marquée « STUB, NON RATIFIÉ » dans le document de travail interne ; (iii) délégation de l'authenticité et de l'extraction du document à un prestataire tiers établi, sous contrat de traitement de données — obligation découlant du traitement de données personnelles par un sous-traitant pour le compte du responsable (art. 5 let. k LPD), inscrite dans les principes généraux des art. 6 et 8, sans citer ici de numéro d'article de sous-traitance au-delà de cette définition, celle-ci n'ayant pas été confirmée par rapport au texte intégral de la loi ; (iv) aucun moteur de reconnaissance faciale biométrique développé en interne par la plateforme.

7Avec qui nous partageons les données

Nous partageons des données personnelles, dans la mesure nécessaire à chaque finalité décrite à la section 4, avec :

Le prestataire tiers de vérification d'identité et de documents (KYC/IDV), pour la vérification documentaire du chauffeur, y compris l'extrait de casier judiciaire le cas échéant (section 4.2). Nom commercial publié dans cette section dès que la sélection sera finalisée ; disponible entre-temps sur demande via le canal de contact de la section 15.
Stripe, pour le traitement de l'abonnement mensuel du chauffeur (section 4.9) — jamais pour le paiement de la course.
Cloudflare, en tant que prestataire d'infrastructure de stockage (R2) pour la photo du lieu de prise en charge (section 4.4).
L'autorité cantonale compétente, lorsque requis pour valider l'autorisation de transport du chauffeur, ou en vertu d'une obligation légale.
L'autorité de surveillance (PFPDT) ou toute autre autorité compétente, lorsque la loi l'exige.

Nous ne vendons pas de données personnelles à des tiers. Nous ne partageons pas de données de course identifiables à des fins de publicité de tiers.

8Transfert international de données (art. 16-17 LPD)

Tout sous-traitant situé hors de Suisse qui produit un effet sur un utilisateur en Suisse est soumis à la LPD en vertu de son champ d'application territorial (art. 3 §1). Lorsqu'un de nos prestataires (par exemple le prestataire KYC/IDV, ou Stripe, selon la juridiction de traitement) est établi hors de Suisse et en l'absence d'une décision d'adéquation du Conseil fédéral (art. 16 §1), le transfert repose sur l'une des bases de l'art. 16 §2 : des clauses-types approuvées par le PFPDT (al. d), des clauses contractuelles de protection des données préalablement notifiées à la même autorité (al. b), ou une autre base équivalente de la norme ; à titre alternatif, sur les exceptions de l'art. 17 §1, notamment le consentement explicite (al. a) ou le lien direct avec un contrat (al. b).

Note de vérification de la source, sur les lettres citées de l'art. 16 §2 et de l'art. 17 §1 ci-dessus : comme déjà indiqué à la section 3 pour l'art. 31 §2 al. a, le registre des sources primaires tenu en interne pour cette politique (Partie A, « Art. 16-17 ») présente ces lettres par résumé/paraphrase du compilateur — « verbatim, résumé aux lettres opérationnelles », dans le texte même de la source — et non par transcription littérale et numérotée du texte intégral des deux articles, contrairement aux art. 5, 6, 8, 19 et 25, cités dans cette politique à partir d'une copie littérale extraite via pdftotext du PDF officiel Fedlex. L'existence des quatre mécanismes cités ci-dessus (clauses-types approuvées par le PFPDT, clauses contractuelles préalablement notifiées à la même autorité, consentement explicite, lien direct avec un contrat) est utilisée dans cette politique avec un niveau de confiance élevé ; le libellé exact de chaque lettre (al. b et al. d de l'art. 16 §2 ; al. a et al. b de l'art. 17 §1) demeure à un niveau de confiance moyen, sous réserve de confirmation directe par rapport au texte intégral de l'art. 16 et de l'art. 17 sur Fedlex ou d'un avis d'un avocat suisse licencié — le même standard de précaution déjà appliqué à l'art. 31 §2 al. a (section 3) et à l'art. 9 (voir le registre juridique interne détaillé tenu à cet effet).

La base spécifique des art. 16/17 applicable à chaque prestataire concret — KYC/IDV, Stripe, selon la juridiction de traitement effective — est déterminée et publiée dans cette section, par prestataire, avant que ne débute tout transfert de données personnelles vers ce prestataire. Aucun transfert international de données personnelles n'a lieu sans que la base de l'art. 16 §2 ou l'exception de l'art. 17 §1 applicable ne soit identifiée et consignée ici.

9Conservation des données — critère, selon l'art. 25 §2 al. d LPD

Conformément à l'art. 6 §4 LPD, nous détruisons ou anonymisons les données personnelles dès qu'elles ne sont plus nécessaires à la finalité du traitement. L'art. 25 §2 al. d LPD exige que nous informions la personne concernée de « la durée de conservation des données personnelles ou, si cela n'est pas possible, les critères pour déterminer cette durée » — la loi accepte expressément le critère comme alternative valable à un délai fixe, et c'est la position adoptée par cette politique.

Critère appliqué, par catégorie de données :

Données de course identifiables : nécessaires pendant le cycle de vie opérationnel de la course (section 4.7, phase 1) ; à la fin de la course, la donnée bascule vers un historique anonymisé par hachage irréversible (section 4.7, phase 2) — dès ce moment, elle n'existe plus sous forme identifiable.
Photo du lieu de prise en charge : conception de suppression automatique 24 heures après le téléversement (section 4.4) — mécanisme exécutable en attente de la construction du module course/chat et de la ratification RLS, selon la note de cette section.
Messages du chat de la course : suppression effective (hard delete) à la clôture de la course — critère déjà arrêté, mécanisme exécutable en attente selon la note de la section 4.5.
Document du chauffeur : conservé tant que l'autorisation de transport reste active — cette composante est la conception déjà figée, applicable dès à présent. État de mise en œuvre, avec précision : cette politique propose en outre un délai de conservation post-désactivation dérivé d'une obligation légale cantonale applicable au canton d'inscription du chauffeur ; cette obligation cantonale spécifique n'a pas encore été identifiée par une source primaire du projet — la section 4.2 elle-même reconnaît déjà cette lacune quant à la fréquence de renouvellement et à la vérification continue des antécédents. Contrairement aux trois critères précédents (course, photo, chat), qui relèvent d'une conception architecturale déjà figée et vérifiable dans le schéma, ce quatrième critère demeure partiellement ouvert : « conservé tant que l'autorisation reste active » s'applique dès à présent ; le délai supplémentaire lié à une obligation légale cantonale ne pourra être appliqué qu'à partir du moment où cette obligation sera identifiée et citée par une source primaire ou un avis juridique.

Telle est la position de cette politique sur la conservation : un critère, selon l'art. 25 §2 al. d, appliqué à chaque catégorie de données décrite dans cette politique, sans délai numérique unique pour toutes les catégories — car aucune d'elles n'exige le même délai, et la loi permet expressément cette forme de réponse. Trois des quatre catégories ci-dessus (course, photo, chat) ont un critère entièrement arrêté, ancré dans une conception architecturale déjà figée. La quatrième (document du chauffeur) a sa composante principale — conservation tant que l'autorisation reste active — également arrêtée, avec la composante supplémentaire de délai cantonal encore ouverte, selon la note spécifique à ce point ci-dessus ; cette politique sera mise à jour dès que cette obligation cantonale sera identifiée par une source primaire.

10LPD et RGPD — double information

Cette politique s'applique, en règle générale, en vertu de la Loi fédérale suisse sur la protection des données (LPD/FADP/nDSG), qui s'applique à toute situation ayant des effets en Suisse, même si elle trouve son origine à l'étranger (art. 3 §1).

Le module Cargo B2B (section 4.10) peut impliquer des clients ou des transporteurs situés dans l'Union européenne. Position opérationnelle finale de cette politique : lorsque le client ou le transporteur du module Cargo est établi dans l'Union européenne/l'Espace économique européen, ou lorsque le traitement vise à offrir un service à une personne concernée dans l'UE, ou à surveiller son comportement, DirectTransfer applique cumulativement, à ces flux spécifiques, le standard le plus protecteur entre la LPD et le Règlement général sur la protection des données (RGPD/GDPR) — en tant que politique de conformité préventive, et non comme reconnaissance juridique définitive d'une applicabilité stricte du RGPD à DirectTransfer. Cela inclut, au minimum, la mise à disposition de la personne concernée de l'UE des mécanismes de droit d'accès, de portabilité et d'effacement déjà décrits à la section 13, même là où la LPD seule exigerait moins. Un avis juridique formel sur le périmètre exact d'applicabilité stricte du RGPD à ces flux sera obtenu avant le lancement commercial transfrontalier du module Cargo ; cette politique sera mise à jour avec la base légale RGPD spécifique par finalité, y compris, si nécessaire, la désignation d'un représentant dans l'UE, dès que cet avis sera disponible.

Distinction nécessaire, non encore évaluée : l'éventuelle obligation de désigner un représentant dans l'Union européenne (art. 27 RGPD), le cas échéant, constitue une obligation structurelle distincte de « l'application du standard le plus protecteur en matière de droits » décrite ci-dessus — la première exige un point de contact formel établi dans l'UE, et non uniquement la reproduction des mécanismes d'accès, de portabilité et d'effacement. Cette politique n'évalue pas, dans cette version, si cette obligation structurelle s'applique ; cette évaluation dépend du même avis juridique formel déjà mentionné ci-dessus.

11Législation cantonale applicable

Outre la LPD fédérale, l'inscription et l'exploitation du chauffeur sont soumises à la législation cantonale sur les transports (par exemple, LTVTC à Genève, règlement 740.25 dans le canton de Vaud, LMob art. 197 à Fribourg), avec l'exigence d'une autorisation propre de « diffuseur de course » dans certains cantons, indépendamment du statut d'emploi du chauffeur. Cette politique ne traite que du traitement des données personnelles ; le fondement réglementaire du transport est décrit dans les documents internes de conformité du projet, non dupliqué ici.

Champ d'application géographique effectif de cette politique : le régime de conservation et de traitement des données personnelles décrit dans cette politique s'applique aux opérations effectivement actives de la plateforme — aujourd'hui, aux cantons dont l'exploitation est effectivement rattachée, à savoir Zurich. L'exigence est non négociable et réelle : l'activation de Genève, de Vaud ou de Fribourg nécessite un avis juridique cantonal formel préalable d'un avocat suisse licencié (selon la revue de sécurité et de conformité interne de la plateforme), et DirectTransfer n'exploite ni ne traite de données personnelles de course dans ces trois cantons tant que cet avis n'existe pas. État de mise en œuvre, avec précision — le mécanisme technique de blocage et la décision juridique de réactivation ne sont pas la même chose : le mécanisme technique concret qui applique ce blocage — une passerelle « fail-closed » par canton, appliquée à chaque point d'entrée créant ou réactivant une autorisation cantonale de chauffeur — est déjà implémenté dans le service backend de la plateforme et couvert par des tests automatisés confirmant qu'il bloque correctement Genève, Vaud et Fribourg tout en autorisant les autres cantons ; il ne s'agit pas d'une simple proposition technique, la protection existe déjà et est vérifiée aujourd'hui, indépendamment de l'environnement. Ce qui demeure en attente n'est pas ce mécanisme technique, mais l'avis juridique substantiel d'un avocat suisse licencié qui déterminera si et quand Genève, Vaud ou Fribourg seront réactivés ; tant que cet avis n'existe pas, la passerelle « fail-closed » continue de rejeter toute tentative de créer ou de réactiver une autorisation de chauffeur dans ces trois cantons. Cette politique sera mise à jour avec le régime cantonal spécifique au moment de l'activation de tout nouveau canton.

12Sécurité de l'information (art. 8 LPD)

Nous appliquons des mesures techniques et organisationnelles adaptées au risque pour garantir un niveau de sécurité des données approprié et prévenir les violations de la sécurité des données (art. 8 §1-2). La conception de sécurité déjà figée comprend le contrôle d'accès par rôle (RBAC) et la sécurité au niveau des lignes (Row Level Security, RLS) sur les tables de course, de document et de données personnelles, selon la matrice RBAC et les exigences RLS déjà spécifiées par la revue de sécurité et de conformité interne de la plateforme.

État de mise en œuvre, avec précision : le contrôle d'accès par rôle (RBAC) est construit, testé et opérationnel dans le service backend de la plateforme pour les flux déjà construits à ce jour (inscription du chauffeur, y compris l'accès aux documents, selon la section 6) ; les flux non encore construits (course, chat, historique de course) n'ont pas encore d'application active, faute d'existence du module sous-jacent. Les politiques concrètes de sécurité au niveau des lignes de la base de données (RLS) demeurent consignées uniquement dans un document de travail interne, explicitement marqué « STUB, NON RATIFIÉ » — ce document fixe l'intention fonctionnelle au niveau SQL pour accélérer le travail de l'équipe de sécurité interne, mais ne constitue pas la politique finale ; la ratification par l'équipe de sécurité interne est une condition préalable avant que la RLS puisse être présentée comme une mesure de sécurité déjà active en production, y compris pour les flux déjà construits. Cette section décrit donc la conception de sécurité déjà figée et l'architecture cible ; l'application du RBAC est opérationnellement vérifiée pour les flux construits à ce jour, celle de la RLS ne l'est pas encore, dans l'attente de cette ratification.

En cas de violation de la sécurité des données susceptible d'entraîner un risque élevé pour votre personnalité ou vos droits fondamentaux, nous en informons le PFPDT dans les meilleurs délais (art. 24 §1) et vous en informons directement, si cela est nécessaire à votre protection ou si l'autorité l'exige (art. 24 §4).

13Vos droits

En vertu de la LPD, vous avez le droit :

D'accès (art. 25) : de confirmer si nous traitons des données personnelles vous concernant et d'obtenir, entre autres, l'identité et les coordonnées du responsable du traitement, les données traitées elles-mêmes, la finalité, la durée de conservation ou le critère permettant de la déterminer (section 9), l'origine des données lorsqu'elles n'ont pas été collectées directement auprès de vous, et les destinataires (section 7). Nous répondons, en règle générale, dans un délai de 30 jours (art. 25 §7), gratuitement (art. 25 §6). Ce droit ne peut faire l'objet d'une renonciation anticipée (art. 25 §5).
De rectification (art. 32) : de demander la rectification de données personnelles inexactes.
À la portabilité (art. 28-29) : de demander l'exportation, dans un format électronique courant, des données traitées avec votre consentement ou en lien direct avec un contrat vous concernant.
D'opposition à une communication indue (art. 30-31) : la communication de vos données sensibles à des tiers exige un motif justificatif propre (par exemple, l'exécution d'un contrat, art. 31 §2 al. a) ; vous pouvez contester une communication dépourvue d'un tel motif.
De réclamation auprès de l'autorité de surveillance : vous pouvez déposer une réclamation auprès du PFPDT (art. 4).

13.1Droit à l'oubli — mécanisme actuel

La destruction ou l'anonymisation des données dès qu'elles ne sont plus nécessaires est une obligation légale du responsable du traitement, non une option (art. 6 §4), et l'art. 32 permet de demander la rectification de données inexactes. Mécanisme actuel, définitif tant que le libre-service n'est pas implémenté : toute demande de suppression anticipée de vos données est traitée manuellement via le canal de contact de la section 15 ; nous répondons dans le délai de l'art. 25 §7 (30 jours), appliqué ici par analogie à la demande de suppression — une extension raisonnable du délai, non une garantie identique au champ littéral de l'art. 25 §7, qui concerne le droit d'accès et non l'exécution d'une demande de suppression, et donc soumise à l'examen d'un avocat suisse licencié avant d'être considérée comme un délai définitif ; et nous confirmons par écrit l'exécution de la demande ou, le cas échéant, la base légale motivant un éventuel refus (par exemple, une obligation légale cantonale de conservation documentaire encore en vigueur, section 4.2). Un mécanisme de libre-service direct permettant à la personne concernée d'exécuter cette demande sans intervention manuelle pourra être mis à disposition à l'avenir ; cette section sera mise à jour lorsque cela se produira, sans modifier le droit lui-même, déjà garanti par le mécanisme manuel décrit ci-dessus.

14Analyse d'impact relative à la protection des données (art. 22)

Nous reconnaissons que le traitement de données personnelles sensibles à grande échelle, tel que la vérification documentaire du chauffeur (sections 4.2, 6), peut déclencher l'obligation de réaliser une analyse d'impact relative à la protection des données avant le traitement, conformément à l'art. 22 §1-2 al. a. Cette analyse relève de la responsabilité conjointe de l'équipe interne de sécurité et de conformité et de l'équipe juridique interne avant le lancement, et son résultat peut entraîner des ajustements de cette politique.

15Contact

Pour exercer l'un quelconque des droits de la section 13, ou pour toute question concernant ce document : privacidade@directtransfer.ch.

16Consentement, clickwrap et enregistrement d'audit

Lorsque cette politique ou toute condition de service exige votre consentement — par exemple, lors de l'inscription du compte, lors de la soumission du document sensible du chauffeur (section 6), ou lors de l'acceptation de cette politique elle-même — l'acceptation se fait par clickwrap explicite, jamais par inaction ou navigation silencieuse. Chaque acceptation génère un enregistrement d'audit comportant, au minimum : l'identifiant de l'utilisateur ayant accepté, la version exacte du document accepté, et l'horodatage de l'acceptation. Cet enregistrement permet de prouver, à tout moment, ce qui a été accepté, par qui et quand — condition de validité du consentement volontaire et spécifique exigé par l'art. 6 §6 LPD.

La structure technique exacte de cet enregistrement d'audit (schéma de table, conservation du journal de consentement lui-même) relève de la responsabilité de l'équipe d'architecture de données compétente, selon la règle de gouvernance d'ingénierie interne de ce projet relative à la propriété exclusive des contrats techniques partagés — cette politique définit l'exigence légale, non le schéma technique.

17Modifications de cette politique

Nous pouvons mettre à jour cette politique pour refléter un changement dans le traitement des données, dans le droit applicable, ou dans la plateforme. Une modification substantielle est communiquée de manière visible avant son entrée en vigueur, et chaque version est identifiée par un numéro et une date, selon le même mécanisme d'enregistrement de version que la section 16.

Historique des versions :

Version 1.0 — 2026-08-22 : première version définitive de ce document, remplaçant le brouillon de travail précédent. Intègre les corrections déjà apportées lors de précédentes rondes de contrôle croisé interne de sécurité et de conformité et de débat contradictoire critique interne, et arrête la position finale concernant la conservation (section 9), le périmètre cantonal actif (section 11), la double information LPD/RGPD pour le module Cargo (section 10) et le mécanisme de droit à l'oubli (section 13.1). S'agissant de l'information relative à l'appel GSM natif (section 4.6), elle arrête le texte d'information et présente l'ancrage juridique le plus proche disponible (art. 19 §2 al. c + art. 6 §2), mais n'arrête pas, à elle seule, la confirmation de la suffisance juridique de cet ancrage pour le scénario spécifique — cette confirmation demeure du ressort de la revue de sécurité et de conformité interne de la plateforme, selon la note de la section 4.6 elle-même. Correction ponctuelle du 2026-08-23 (section 11) : le texte précédent décrivait la passerelle « fail-closed » de blocage cantonal comme encore « une proposition technique, non une décision » — cette description était obsolète. La vérification technique directe du code a confirmé que le mécanisme est déjà implémenté et couvert par des tests automatisés ; seul l'avis juridique substantiel d'un avocat suisse licencié sur la réactivation de ces cantons demeure en attente. Fribourg a également été ajouté explicitement aux côtés de Genève et de Vaud, ce canton étant lui aussi bloqué dans le code.