01
Le présent document identifie les principaux prestataires externes autorisés à traiter des données personnelles dans le cadre de la Solution La Vie de Château (« LVC »). Il distingue les Sous-traitants ultérieurs au sens de l’article 28 du RGPD des prestataires qui, pour certaines opérations, agissent en qualité de responsable de traitement indépendant ou selon un régime juridique mixte.
L’inscription d’un prestataire dans ce registre constitue une autorisation de principe de l’utiliser pour les finalités indiquées. Elle ne signifie pas que toutes les fonctionnalités sont activées pour tous les Clients, ni que toutes les catégories de données sont transmises à chaque prestataire. LVC applique une logique de minimisation par fonctionnalité, environnement et finalité.
Règle de lecture — La colonne « Statut LVC » indique si le prestataire est actif, autorisé ou activable selon l’environnement. Un prestataire autorisé mais non activé ne reçoit aucune donnée tant que la fonctionnalité correspondante n’est pas mise en production.
02
| Situation | Rôle principal de LVC | Rôle du prestataire | Conséquence |
|---|
| CRM, réservations et données locales traitées pour le restaurant | Sous-traitant du Client | Sous-traitant ultérieur de LVC lorsqu’il traite ces données pour LVC | Chaîne article 28 : Client → LVC → prestataire. |
| Profil Réseau LVC, consentement réseau, indicateurs et scoring | Responsable de traitement pour ses finalités propres | Sous-traitant de LVC lorsqu’il héberge/traite ces données sur instructions de LVC | LVC demeure responsable de la finalité réseau et de la gouvernance. |
| Paiement et obligations réglementaires du PSP | Selon le flux : client de Stripe / plateforme technique | Stripe peut être processeur et/ou responsable indépendant | Les rôles exacts sont déterminés par les conditions Stripe et la configuration du paiement. |
| Google Maps / Places | Client professionnel du service cartographique | Responsable indépendant pour certains traitements Maps | Aucune donnée de Profil Réseau n’est volontairement fournie à Google Maps par défaut. |
| Messagerie administrative grand public | Responsable de traitement | Fournisseur selon ses propres conditions | Usage limité au support ; pas de transfert massif du Réseau LVC. |
La qualification réelle prévaut sur toute dénomination contractuelle. Lorsqu’un fournisseur impose un rôle de responsable indépendant pour certaines opérations, LVC ne le présente pas artificiellement comme un sous-traitant afin de préserver l’exactitude du dispositif RGPD.
03
| Prestataire / entité | Fonction LVC | Données susceptibles d’être traitées | Localisation cible / transferts | Statut LVC |
|---|
| Render Services, Inc. | Hébergement applicatif, exécution serveur, réseau, journaux techniques | Requêtes applicatives, identifiants, données nécessaires au traitement en mémoire, logs techniques, secrets de configuration protégés | Région de production cible : Francfort (Allemagne). Render est une entité américaine et peut recourir à des sous-traitants internationaux sous son DPA. | Actif / essentiel |
| Supabase, Inc. | Base PostgreSQL, authentification, stockage, API backend, fonctions temps réel selon activation | Données Établissement ; utilisateurs ; réservations ; consentements ; Données Réseau ; indicateurs dérivés et scores ; logs applicatifs | Région spécifique UE à privilégier : Paris (eu-west-3) ; à défaut Francfort (eu-central-1). Transferts résiduels possibles selon son DPA et ses sous-traitants. | Autorisé — architecture cible / essentiel dès bascule |
| Stripe Payments Europe, Limited / Stripe Technology Europe, Limited selon le service | Facturation B2B LVC ; paiements ; éventuelles garanties/acompte via configuration du restaurant | Identité, coordonnées de facturation, montants, statuts, jetons, références de transaction, données de paiement traitées par Stripe | EEE / réseau mondial Stripe selon service ; mécanismes de transfert prévus par le DPA Stripe. | Autorisé / activé selon parcours |
| Google Cloud France / Google Maps Platform | Cartographie, Places, géocodage, enrichissement des fiches établissements | Données de lieux, adresses, requêtes techniques, données d’usage et informations directement transmises à Google par le terminal selon le service | Régime Google Maps applicable ; transferts selon les conditions Google. | Autorisé / activé selon fonctionnalité |
Prestataires exclus du cœur réseau par défaut — À la version 1.0, aucun fournisseur d’IA générative, outil publicitaire, data broker ou plateforme d’analytics marketing n’est autorisé à recevoir les profils réseau identifiants, scores, historiques inter-établissements ou dépenses moyennes. Toute activation future exige l’ajout préalable au registre et une revue RGPD/sécurité.
04
Render est utilisé pour exécuter l’application LVC et les services backend associés. Dans la mesure où des données personnelles transitent par les services d’hébergement pour fournir la Solution, Render intervient comme sous-traitant de LVC ou sous-traitant ultérieur lorsque LVC agit lui-même pour le compte d’un Client professionnel.
| Point | Règle LVC |
|---|
| Finalités autorisées | Exécution de l’application, traitement des requêtes, mise en réseau, déploiement, disponibilité, logs techniques strictement nécessaires et dépannage. |
| Données réseau | Traitement transitoire et opérationnel possible pour servir les écrans/API. LVC évite d’utiliser Render comme entrepôt secondaire autonome de profils réseau si Supabase est la base de vérité. |
| Région | Les services de production contenant ou traitant les données cœur doivent être placés à Francfort lorsque la configuration Render le permet. |
| Sous-traitants du fournisseur | Render publie sa propre liste, comprenant notamment des fournisseurs d’infrastructure/cloud. Ces sous-traitants de rang ultérieur sont encadrés par le DPA Render. |
| Accès support | Accès fournisseur limité aux besoins du service et régi par ses engagements contractuels ; LVC limite également ses propres accès privilégiés. |
| Transferts | Lorsqu’un transfert international intervient, LVC s’appuie sur les mécanismes reconnus prévus dans le DPA du fournisseur et effectue une revue de risque proportionnée. |
Le DPA public de Render indique Render Services, Inc. comme cocontractant et prévoit une autorisation générale de sous-traitants, avec information préalable des nouveaux sous-traitants et mécanismes de transfert adaptés. LVC s’aligne contractuellement sur ce fonctionnement pour la chaîne de sous-traitance.
05
Supabase est le prestataire privilégié pour devenir la source de vérité technique de LVC. Compte tenu de la sensibilité économique et réglementaire du Réseau LVC, sa configuration doit réduire au maximum la dispersion des données et conserver les profils identifiants dans une infrastructure principale clairement identifiée.
| Point | Règle LVC |
|---|
| Région de projet | Choisir une région spécifique de l’Union européenne plutôt qu’un regroupement géographique générique. Cible prioritaire : Paris (eu-west-3) ; alternative : Francfort (eu-central-1). |
| Données persistantes | CRM local, réservations, comptes, autorisations, preuve de consentement réseau, Profil Réseau, événements de fiabilité, dépense moyenne, indicateurs et scores lorsque liés à une personne. |
| Isolation | Séparation multi-tenant par identifiants d’établissement, politiques d’accès applicatives et, lorsque pertinent, règles de sécurité au niveau des lignes (RLS). |
| Accès réseau | L’accès d’un restaurant à un Profil Réseau doit passer par la logique LVC et non par un accès direct générique à la base. |
| Export | Les fonctions d’export d’un restaurant excluent les profils globaux, données d’autres établissements, méthodes de scoring et enrichissements réseau dont il ne dispose pas d’un droit autonome. |
| Sous-traitants Supabase | Supabase peut recourir à ses propres sous-traitants listés dans son DPA. LVC n’intègre pas automatiquement toutes ces sociétés comme prestataires directs : elles constituent la chaîne de rang suivant de Supabase. |
| Évolution | Le changement de région, de projet ou d’architecture exige une revue de localisation, sauvegardes, accès, logs et transferts avant production. |
Règle stratégique — Le Réseau LVC peut croître sans multiplier les destinataires : la valeur produit provient du partage contrôlé entre établissements autorisés, pas de l’envoi des profils à de nombreux fournisseurs externes. Le cœur réseau doit donc rester centralisé et gouverné par LVC.
06
Stripe intervient pour les abonnements B2B de LVC et peut, selon l’architecture de paiement retenue, intervenir dans les paiements, acomptes ou garanties liés aux réservations. Stripe indique dans son DPA qu’il peut agir tantôt comme processeur, tantôt comme responsable de traitement, notamment pour ses obligations réglementaires, la fraude, la sécurité et certains services financiers.
- Minimisation : LVC ne transmet à Stripe que les données nécessaires au paiement, à la facturation, à la prévention de la fraude et au rapprochement technique.
- Cartes : LVC ne stocke pas volontairement le numéro complet de carte ni le cryptogramme ; les données complètes sont destinées à être traitées par Stripe.
- Réseau : le score LVC, l’historique détaillé inter-établissements, les notes internes et la dépense moyenne réseau ne sont pas transmis à Stripe par défaut.
- Restaurant : lorsque le paiement est effectué sur le compte Stripe du restaurant, les rôles de LVC, du restaurant et de Stripe dépendent du produit Stripe utilisé et du flux effectivement configuré.
- Preuve : LVC peut conserver des identifiants de transaction, statuts, montants, jetons et traces nécessaires à l’exécution du service, aux litiges et à la sécurité.
07
Google Maps Platform est utilisé pour les cartes, la recherche de lieux, les informations d’établissement et certains enrichissements géographiques. Les conditions Google Maps prévoient, pour certains traitements, une relation de responsables indépendants. LVC limite donc strictement ce qui est transmis à Google.
| Autorisé | Interdit par défaut |
|---|
| Adresse ou identifiant d’un restaurant, requête Places, coordonnées géographiques, paramètres cartographiques nécessaires. | Profil Réseau complet d’un Client final, score de fiabilité, dépenses moyennes individuelles, no-shows détaillés, notes internes. |
| Données techniques automatiquement nécessaires au chargement du service et traitées selon les conditions Google. | Utiliser Google Maps comme base CRM ou mécanisme de synchronisation des profils clients LVC. |
| Données publiques d’établissement retournées par Places dans le respect des conditions du service. | Associer à Google une liste exportée de clients ou l’historique réseau dans le seul but d’enrichir commercialement les profils. |
Cette séparation permet à LVC de conserver tout le potentiel des cartes et de l’enrichissement des fiches restaurants sans exposer inutilement la base réseau ni transformer Google en destinataire du scoring LVC.
08
L’adresse de contact actuelle de LVC est laviedechateau.fr@gmail.com. Les échanges reçus peuvent contenir des coordonnées professionnelles ou des éléments transmis volontairement par l’expéditeur. Cette messagerie ne constitue pas la base de données principale de LVC et ne doit pas être utilisée comme canal d’export massif du Réseau LVC.
- Les équipes LVC ne joignent pas par défaut de dumps de base, exports complets de profils réseau ou données de carte à un e-mail de support.
- Lorsqu’un diagnostic nécessite un exemple, LVC privilégie un identifiant technique, une donnée minimisée, un extrait pertinent ou une donnée pseudonymisée.
- Avant montée en charge commerciale, LVC peut migrer la messagerie vers une offre professionnelle disposant d’engagements contractuels adaptés ; le registre sera alors mis à jour.
- Le futur prestataire d’e-mails transactionnels ou de SMS devra être ajouté au registre avant de recevoir des données de production.
09
Pour maximiser le potentiel du partage réseau tout en maintenant une gouvernance défendable, LVC applique une logique de « noyau réseau fermé » : les profils identifiants sont principalement stockés dans la base cœur, et seuls les prestataires indispensables peuvent les traiter.
| Type de donnée réseau | Stockage / traitement autorisé | Partage externe par défaut |
|---|
| Identité et coordonnées | Base cœur LVC ; application LVC ; messagerie transactionnelle uniquement si nécessaire | Non, sauf fonction nécessaire ou obligation légale. |
| Réservations honorées / no-shows / annulations tardives | Base cœur + calculs LVC | Non vers cartographie, marketing ou analytics publicitaires. |
| Dépense moyenne / valeur client | Base cœur + indicateurs LVC | Non vers Stripe sauf montant d’une transaction précise ; jamais comme profil marketing externe. |
| Score de fiabilité / statut | Base cœur + interfaces restaurant autorisées | Non vers prestataires externes par défaut. |
| Notes internes | Espace local de l’établissement uniquement | Jamais dans le Réseau LVC par défaut. |
| Données sensibles | Hors Réseau LVC par défaut | Aucun partage réseau ou prestataire non spécifiquement encadré. |
| Données anonymisées et agrégées | Peuvent être utilisées pour statistiques, benchmark, amélioration produit et sécurité | Peuvent être traitées plus largement si l’anonymisation est effective et irréversible de façon raisonnable. |
Potentiel LVC — LVC se réserve la possibilité de produire des statistiques agrégées, benchmarks de réseau, tendances de réservation et indicateurs de performance à partir de données effectivement anonymisées. Une fois l’anonymisation effective, ces informations ne constituent plus des données personnelles et peuvent être conservées et exploitées pour améliorer et valoriser la Solution, sans permettre la réidentification raisonnable d’un Client final.
10
Aucun fournisseur futur d’IA, d’analytics, de CRM marketing, d’enrichissement ou de communication n’est autorisé à recevoir des Données Réseau identifiantes du seul fait qu’il est techniquement intégrable. Avant activation, LVC doit réaliser au minimum une revue du rôle RGPD, des finalités, des données, de la localisation, des sous-traitants ultérieurs, des mesures de sécurité et de la compatibilité avec le consentement ou la base juridique applicable.
- Priorité à la pseudonymisation, aux données agrégées ou à l’exécution sans conservation lorsque le cas d’usage le permet.
- Interdiction par défaut d’utiliser les profils réseau LVC pour entraîner un modèle tiers à des fins propres au fournisseur.
- Pas d’activation silencieuse d’un prestataire qui réutiliserait les données à des fins publicitaires ou de constitution de profils propres.
- Ajout au présent registre avant toute réception de données personnelles de production et notification des Clients lorsque le DPA l’exige.
11
LVC privilégie les régions de traitement situées dans l’Espace économique européen pour les données cœur. La localisation primaire ne signifie toutefois pas qu’aucun accès ou transfert international ne puisse survenir : certains fournisseurs, leurs sociétés affiliées ou leurs sous-traitants peuvent traiter des données hors EEE pour le support, la sécurité, la maintenance ou l’infrastructure.
- Lorsqu’un transfert vers un pays tiers est nécessaire, LVC s’appuie sur un mécanisme reconnu au chapitre V du RGPD : décision d’adéquation, clauses contractuelles types de la Commission européenne ou autre mécanisme valide.
- LVC peut s’appuyer sur les garanties contractuelles et évaluations de transfert de ses fournisseurs lorsque celles-ci couvrent le service utilisé, tout en conservant une obligation de diligence raisonnable.
- LVC peut imposer des mesures complémentaires, notamment limitation d’accès, chiffrement, pseudonymisation, choix de région ou réduction des catégories de données transmises.
- Un changement de mécanisme de transfert chez un fournisseur ne constitue pas automatiquement une modification substantielle du service si un mécanisme légal équivalent ou plus protecteur le remplace.
12
Le Client professionnel accorde à LVC une autorisation générale de recourir aux Sous-traitants ultérieurs nécessaires à la fourniture, la sécurité, l’évolution et la continuité de la Solution, conformément au DPA.
| Étape | Règle |
|---|
| Évaluation | LVC vérifie raisonnablement le rôle, la finalité, les garanties de sécurité, la localisation et les conditions de traitement du nouveau prestataire. |
| Ajout au registre | Le prestataire est inscrit avec sa fonction et les catégories de données susceptibles d’être traitées avant ou au plus tard lors de son activation matérielle. |
| Information | Lorsque le changement est matériel et que cela est raisonnablement possible, LVC informe les Clients selon le mécanisme prévu au DPA. |
| Délai d’objection | Le Client dispose de dix (10) jours à compter de l’information pour présenter une objection écrite, documentée et fondée sur des motifs sérieux de protection des données. |
| Traitement de l’objection | LVC peut fournir des garanties, modifier le périmètre, proposer une solution de remplacement raisonnable ou empêcher l’accès du prestataire à certaines données. |
| Absence de solution raisonnable | Si le prestataire est nécessaire et qu’aucune alternative raisonnable n’existe, LVC peut suspendre la fonctionnalité affectée ou permettre la résiliation de la partie du service concernée, sans imposer une refonte disproportionnée de son architecture. |
Une objection purement commerciale, générale, non documentée ou destinée à imposer au SaaS une architecture propre à un Client n’oblige pas LVC à remplacer un prestataire standard de sa plateforme.
13
Les fournisseurs de premier rang peuvent eux-mêmes faire appel à des sous-traitants. LVC ne reproduit pas intégralement dans son propre registre les listes mouvantes de chaque fournisseur, mais conserve une référence vers leurs pages ou DPA officiels et évalue les changements importants selon le risque.
| Fournisseur | Référence de transparence fournisseur |
|---|
| Render | DPA : https://render.com/dpa — sécurité / sous-traitants : https://render.com/security |
| Supabase | DPA et liste de sous-traitants publiés dans les documents juridiques Supabase : https://supabase.com/legal |
| Stripe | DPA : https://stripe.com/legal/dpa — prestataires / sous-traitants : https://stripe.com/legal/service-providers |
| Google Cloud / Maps | Conditions et ressources de protection des données : https://cloud.google.com/product-terms |
14
- Nécessité : aucun fournisseur ne doit recevoir plus de données que nécessaire au service concerné.
- Contrat : lorsque le fournisseur agit comme processeur, LVC privilégie un DPA intégrant les exigences de l’article 28 et, le cas échéant, les garanties de transfert.
- Sécurité : examen raisonnable des garanties disponibles, certifications, pratiques de chiffrement, gestion des accès et processus d’incident.
- Région : sélection des régions européennes pour le cœur de données lorsque l’offre du fournisseur le permet.
- Réversibilité : éviter les dépendances qui empêcheraient une migration raisonnable des données cœur.
- Données réseau : accès externe restreint ; aucun droit général de réutilisation commerciale du Profil Réseau accordé aux fournisseurs.
- Audit continu : revue du registre à chaque évolution importante de l’architecture et au minimum périodiquement pendant la phase de croissance.
15
La version à jour du présent registre peut être communiquée par e-mail, mise à disposition dans l’espace professionnel LVC ou publiée sur une page juridique du site. LVC peut retenir comme adresse de publication dédiée : laviedechateauu.com/legal/sous-traitants, sous réserve de sa mise en ligne effective.
La date de mise à jour et le numéro de version permettent de démontrer la version applicable. Une correction rédactionnelle, un changement de dénomination sociale, une mise à jour d’adresse ou un changement ne modifiant pas substantiellement le risque ne nécessite pas le même préavis qu’un nouveau prestataire recevant une catégorie de données réseau auparavant non partagée.
16
Le présent registre n’a pas pour objet de figer l’architecture de LVC. LVC peut remplacer ou ajouter des prestataires afin d’améliorer les performances, la sécurité, la résilience, les coûts, l’expérience utilisateur, les fonctionnalités ou la couverture géographique, sous réserve du respect du DPA et de la réglementation applicable.
Protection contre le verrouillage fournisseur — Le Client ne dispose d’aucun droit de veto général sur les choix techniques de LVC. Son droit d’objection est limité aux motifs sérieux de protection des données prévus par le DPA. Cette règle protège la capacité de LVC à faire évoluer son infrastructure sans renoncer aux garanties RGPD.
17
Le Client demeure responsable des prestataires qu’il connecte ou active de sa propre initiative en dehors de ceux fournis directement par LVC, notamment une intégration tierce, un outil d’export, un webhook, un CRM externe ou un compte de paiement qu’il administre. Lorsqu’un Client autorise une telle connexion, il lui appartient de vérifier la licéité du transfert et les conditions du destinataire, sauf si LVC a expressément pris cet engagement à sa charge.
Le Client s’interdit d’utiliser les exports, API ou intégrations pour transférer à un tiers des Données Réseau auxquelles il n’a qu’un droit de consultation dans LVC. Toute extraction massive, reconstitution d’une base concurrente ou transmission du scoring à des destinataires non autorisés constitue une violation des règles du Réseau LVC et peut justifier une restriction ou suspension conformément aux CGV.
18
Si LVC est informé d’un incident de sécurité chez un prestataire susceptible d’affecter des données personnelles de LVC, LVC évalue les informations disponibles, prend les mesures raisonnablement nécessaires, peut suspendre un flux ou une intégration et respecte les obligations d’information prévues par son DPA. LVC peut s’appuyer sur les rapports, avis et analyses techniques du fournisseur pour déterminer l’impact réel de l’incident.
19
En complément de la version publique, LVC peut maintenir un registre interne plus détaillé comprenant notamment le propriétaire du service, l’environnement concerné, la date d’activation, les catégories de données, la région, les mécanismes de transfert, les accès privilégiés, les liens contractuels et la date de dernière revue. Ce registre interne peut contenir des informations de sécurité non publiées.
La liste publique ne constitue donc pas une divulgation exhaustive de l’architecture, des mesures de sécurité, des secrets, clés, configurations, adresses internes ou relations techniques dont la publication pourrait créer un risque pour LVC ou les personnes concernées.
20
Le présent registre entre en vigueur à sa date de version. Il complète le DPA / Accord de traitement des données personnelles et les CGV B2B de LVC. En cas de contradiction sur la qualification d’un traitement ou une obligation impérative de protection des données, le DPA et le droit applicable prévalent. Le registre précise l’identité et la fonction des prestataires sans étendre leur droit d’utiliser les données au-delà de ce qui est nécessaire et licite.
Annexe A
| Catégorie | Render | Supabase | Stripe | Google Maps | Messagerie support |
|---|
| Données CRM locales | Oui, si nécessaire au traitement applicatif | Oui — stockage cœur | Non par défaut | Non | Uniquement si support le nécessite |
| Profil Réseau identifiable | Oui, transitoire pour servir l’application | Oui — stockage cœur | Non par défaut | Non | Non par défaut |
| Score / fiabilité | Oui, transitoire | Oui | Non | Non | Non par défaut |
| Dépense moyenne réseau | Oui, transitoire | Oui | Non ; seulement transaction concernée | Non | Non par défaut |
| No-shows / annulations réseau | Oui, transitoire | Oui | Non sauf référence minimale nécessaire au litige paiement | Non | Non par défaut |
| Données carte complètes | Non | Non | Oui, chez Stripe selon service | Non | Non |
| Adresse / lieu restaurant | Oui | Oui si stocké | Éventuellement adresse de facturation | Oui | Oui si échange support |
| Notes internes | Oui, transitoire si affichage | Oui, espace local | Non | Non | Uniquement si le Client les transmet volontairement |
| Données anonymisées | Oui | Oui | Possible si besoin | Possible si nécessaire | Possible |
Annexe B
| Contrôle | Exigence minimale |
|---|
| Finalité | Définie, légitime et compatible avec les documents LVC. |
| Rôle RGPD | Sous-traitant, responsable indépendant ou responsable conjoint identifié selon les faits. |
| Données | Catégories minimisées ; justification spécifique pour toute Donnée Réseau identifiable. |
| DPA | Disponible et accepté lorsqu’un traitement pour le compte de LVC est réalisé. |
| Sécurité | Garanties suffisantes au regard du risque ; accès et authentification maîtrisés. |
| Transferts | Pays/zone et mécanisme chapitre V évalués lorsque nécessaire. |
| Réutilisation | Aucune réutilisation incompatible, publicitaire ou entraînement tiers non autorisé des données réseau. |
| Suppression | Possibilité raisonnable d’effacement ou de sortie des données. |
| Registre | Prestataire ajouté avant réception de données de production. |
| AIPD | AIPD mise à jour si le changement modifie sensiblement le risque du Profil Réseau ou du scoring. |
Annexe C
| Version | Date | Évolution |
|---|
| 1.0 | 29 août 2026 | Création du registre. Identification de Render, Supabase, Stripe et Google Maps ; architecture de minimisation du Réseau LVC ; procédure d’ajout et d’objection ; matrice de diffusion. |
Les informations de dénomination, rôles et mécanismes de traitement ont été rapprochées des documents publics des prestataires disponibles lors de la rédaction : DPA Render, documentation des régions Render, DPA et régions Supabase, DPA et Services Agreement Stripe, et conditions / répertoire contractuel Google Cloud et Google Maps. Les conditions des fournisseurs peuvent évoluer ; le registre opérationnel doit donc être revu lors des changements matériels.
Mise en production recommandée — Configurer Render à Francfort et Supabase dans une région spécifique de l’UE (priorité Paris) avant d’y placer le cœur du Réseau LVC ; ne pas envoyer de profils réseau bruts à Google Maps, Stripe, outils marketing ou futurs fournisseurs d’IA ; ajouter tout prestataire d’e-mail/SMS au registre avant activation. Cette architecture maximise la valeur du réseau tout en réduisant le nombre de destinataires et la surface de risque.
