Sous-traitants · version du 21 août 2026
Qui traite des données pour nous.
Cette liste correspond aux intégrations réellement présentes dans le code de la plateforme. Elle complète la politique de confidentialité.
Les contrats de sous-traitance et les garanties encadrant les transferts hors Union européenne sont en cours de formalisation avec les prestataires dont la région n’est pas documentée ci-dessous.
Prestataires
| Prestataire | Finalité | Catégories de données | Région de traitement |
|---|---|---|---|
| Supabase | authentification, base de données, stockage des fichiers, temps réel, fonctions ; envoie aussi les e-mails de confirmation d’inscription et de réinitialisation de mot de passe | compte, adresse e-mail, mot de passe, profil créateur, offres, messages de session, dossiers de modération, fichiers vendus, journaux | eu-west-3 (Paris) |
| Stripe | encaissement des achats, ouverture et vérification du compte de paiement connecté du créateur, exécution des virements demandés par le créateur | reçus directement par Stripe dans l’Account Onboarding hébergé pour les comptes Express : identité, adresse, date de naissance, acceptation contractuelle, pièces d’identité et IBAN ; reçus directement du navigateur par Stripe dans le parcours embarqué conservé pour certains comptes existants : les mêmes valeurs KYC et, via Stripe.js, l’IBAN ; reçus de Dylup : jeton bancaire btok_ pour ces comptes existants, pays, URL du profil public, identifiant interne, adresse e-mail de l’acheteur, montant, devise et références de la transaction ; renvoyés par Stripe à Dylup dans ses réponses API ou webhooks signés : données réglementaires filtrées en mémoire avant persistance de la seule projection minimale (états, codes d’exigences et métadonnées masquées) | non documentée |
| Resend | e-mails transactionnels (accès, session, sécurité, remboursement) | adresse du destinataire, sujet, corps du message, et pour une réservation un fichier .ics contenant le titre de l’offre, les horaires et le nom du créateur | non documentée |
| Upstash Redis | limitation de débit distribuée (anti-abus) | identifiant de partition haché et compteurs — aucune donnée directement identifiante | non documentée |
| Upstash QStash | déclenchement planifié des tâches de fond | aucune donnée personnelle : uniquement le déclenchement horaire et un secret d’authentification interne | Union européenne |
| Vercel | hébergement de l’application web et exécution des fonctions | requêtes HTTP, adresse IP, journaux techniques | cdg1 (Paris) |
| Apple, Google | Apple Pay et Google Pay, lorsque l’acheteur choisit ce moyen | données de paiement du portefeuille, transmises par le navigateur de l’acheteur | non documentée |
Précisions qui comptent
- Les données de carte ne touchent jamais nos serveurs. Elles sont envoyées directement à Stripe par le navigateur de l’acheteur. Nous ne stockons aucun numéro de carte.
- Les valeurs KYC ne sont pas envoyées à Dylup comme champs entrants. Pour un nouveau compte, Dylup provisionne auprès de Stripe un compte minimal sans valeur KYC brute, mais avec le pays, l’URL du profil public et l’identifiant interne nécessaires à sa liaison, puis le créateur poursuit sur l’Account Onboarding hébergé par Stripe. Stripe y recueille directement le statut de personne physique ou d’entreprise, le nom légal, l’adresse, la date de naissance, l’acceptation contractuelle et les pièces demandées. Les comptes gérés par l’application déjà existants conservent l’Account Onboarding Stripe embarqué dans Dylup. Dylup ne reçoit donc ni les valeurs KYC comme champs entrants ni les octets des pièces. Stripe peut toutefois renvoyer des données réglementaires dans ses réponses API ou ses webhooks signés. Elles sont traitées transitoirement en mémoire puis filtrées avant toute persistance : seuls les états du compte, les codes d’exigences et les métadonnées masquées sont conservés. Aucune valeur KYC brute, aucun octet de pièce et aucun journal qui les contiendrait ne sont persistés. Le mécanisme est décrit dans la documentation Stripe sur l’Account Onboarding hébergé. Le compte connecté reste soumis au contrat de compte connecté Stripe.
- L’IBAN complet ne touche jamais nos serveurs. Pour un nouveau compte Express, il est saisi directement sur la page sécurisée de Stripe. Pour un compte géré par l’application déjà existant, Stripe.js le tokenise directement dans le navigateur du créateur depuis le formulaire RIB Dylup ; Dylup reçoit uniquement le jeton bancaire opaque
btok_…à usage unique. Dylup ne lit ensuite auprès de Stripe que des métadonnées masquées destinées à l’affichage, notamment les quatre derniers chiffres du compte. Stripe ne retourne pas l’IBAN complet : Dylup ne le reçoit et ne l’enregistre jamais. - Dylup transmet encore les métadonnées nécessaires à l’opération. Elles comprennent notamment le pays, l’URL du profil public, l’identifiant interne du créateur, le montant, la devise et les références de transaction ; elles ne contiennent ni valeurs KYC ni octets de pièce d’identité.
- Stripe encaisse et exécute les virements. Les achats sont encaissés par Stripe au moyen de paiements avec transfert vers le compte connecté. Un virement vers l’IBAN enregistré n’est créé qu’à la demande du créateur ; il n’est pas automatique. Dylup exige un calendrier fournisseur manuel avant d’afficher le solde ou de créer le virement ; les contrôles Express permettant de déclencher un virement manuel ou d’en modifier la fréquence restent désactivés.
- L’adresse e-mail de l’acheteur est transmise à Stripe pour l’émission du reçu de paiement.
- La modération automatisée reste dans l’infrastructure Dylup. Le titre et la description sont comparés à une liste de termes versionnée, et l’image d’aperçu est classée par le modèle embarqué dans le serveur. Aucun texte ni octet d’image n’est envoyé à un prestataire de classification. Une offre n’est publiée qu’après un verdict
passed. Un score automatiqueflaggedne refuse pas le contenu : la politique de publication le convertit enpassed. Un verdict expliciteblockedreste bloquant, tandis qu’une panne du classifieur bloque la publication. Le contrôle automatise le tri, jamais une sanction de compte. - Aucun outil de mesure d’audience, de publicité ou de suivi d’erreurs n’est installé, ni sur le web ni dans l’application mobile.
Où se trouve le jeton d’accès
Le lien reçu par l’acheteur contient sa preuve d’accès dans le fragment de l’URL — la partie qui suit le signe #. Les navigateurs ne transmettent jamais cette partie au serveur : elle n’apparaît donc ni dans nos journaux, ni dans ceux de l’hébergeur, ni dans un en-tête de provenance envoyé à un tiers.
Elle voyage en revanche dans l’e-mail qui porte le lien, et reste dans l’historique du navigateur qui l’ouvre. Le lien est personnel et ne doit pas être partagé.