Accord de Sous-Traitance des Données

Version 1.1 · Dernière mise à jour : 8 septembre 2026 · En vigueur depuis le 8 septembre 2026

Le présent Accord de Sous-Traitance des Données (le « DPA ») est conclu au titre de l'article 28 du Règlement (UE) 2016/679 (« RGPD ») et de l'article 28 du Décret législatif italien 196/2003, modifié par le Décret législatif 101/2018 (le Code italien de la protection des données), entre le Commerce, en qualité de Responsable du traitement, et radioBros, en qualité de Sous-traitant, et régit le traitement des données personnelles des clients du Commerce dans le cadre du service TesserApp.

La version 1.1 met le présent DPA en cohérence avec la version 1.2 de la Politique de confidentialité, à la suite d'une revue complète du code source du Service. Elle étend à tous les types de carte personnelle et à l'inscription web sans app les informations qui n'étaient auparavant rédigées que pour les programmes privés ; elle remplace la liste des sous-traitants ultérieurs, le tableau des durées de conservation et la description des mesures de sécurité par ce que les systèmes font réellement ; et elle supprime les engagements qu'aucun processus automatisé n'appliquait. Là où le présent DPA et la Politique de confidentialité décrivent le même traitement, ils sont censés dire la même chose.

La version italienne du présent DPA est la version officielle et prévaut sur les traductions en cas de divergence.

1. Parties

1.1 Responsable du traitement : la personne physique ou morale qui s'inscrit sur la plateforme TesserApp Shop et souscrit au Service (ci-après le « Commerce »). Les informations d'identification du Commerce sont celles saisies à l'inscription et modifiables depuis le tableau de bord.

1.2 Sous-traitant : radioBros di Alberto Miconi, dont le siège est sis Via Ridolfino Venuti 30, 00162 Rome (Italie), numéro de TVA italien (Partita IVA) IT15127451001, e-mail de contact privacy@tesserapp.eu (ci-après « radioBros »).

Les Parties reconnaissent mutuellement les rôles ci-dessus, sans préjudice du rôle indépendant de radioBros en tant que Responsable du traitement pour ses propres traitements dans l'exécution de l'abonnement (facturation, compte Commerce, journaux de sécurité de ses propres systèmes), régis par la Politique de confidentialité et les Conditions générales d'utilisation.

2. Définitions

Les définitions de l'article 4 du RGPD s'appliquent. En outre :

• « Données personnelles » : toute information se rapportant à une personne physique identifiée ou identifiable au sens de l'art. 4, n° 1, du RGPD, traitée par le Sous-traitant pour le compte du Responsable du traitement dans le cadre du Service.
• « Personne concernée » : le client du Commerce titulaire d'une carte de fidélité de l'un des programmes du Commerce, qu'il conserve cette carte dans l'app mobile TesserApp ou uniquement dans Apple Wallet ou Google Wallet.
• « Service » : la plateforme web, les applications mobiles et les composants d'infrastructure que radioBros met à la disposition du Commerce pour l'exploitation de ses programmes de fidélité.
• « Carte personnelle » : une carte qui, par construction, est émise au profit d'une seule personne nommément désignée. Il en existe quatre types : privée (carte à tampons personnelle), remise, accès et prépayée. Pour les quatre, le nom et l'adresse e-mail du titulaire sont obligatoires.
• « Carte anonyme » : une carte standard (à tampons) ou une carte points, que la Personne concernée active elle-même depuis l'app ou depuis le catalogue, et qui ne porte ni nom ni adresse e-mail.
• « Sous-traitant ultérieur » : tout tiers engagé par le Sous-traitant pour traiter des Données personnelles, au titre de l'art. 28, par. 4, du RGPD. La liste figure à l'Annexe A, section A.1.
• « Violation de Données personnelles » : telle que définie à l'art. 4, n° 12, du RGPD.

3. Objet, durée, nature et finalités du traitement

3.1 Le Commerce, en qualité de Responsable du traitement, confie à radioBros, en qualité de Sous-traitant, le traitement des Données personnelles des Personnes concernées pour les finalités nécessaires à la fourniture du Service et énoncées dans le présent DPA.

3.2 Objet : l'exploitation technique du programme de fidélité du Commerce, y compris l'activation des cartes clients, l'enregistrement des transactions (tampons attribués, récompenses échangées, annulations, variations d'un solde de points ou de crédit), la synchronisation des cartes vers Apple Wallet et Google Wallet, l'envoi de notifications push liées au programme de fidélité, la diffusion des annonces que le Commerce rédige à l'intention des titulaires de l'un de ses programmes, l'exposition du programme dans le catalogue de l'app grand public (lorsque le Commerce a opté pour la visibilité publique), la fourniture de fonctionnalités de découverte géolocalisées et, en outre :

• pour les cartes personnelles (privée, remise, accès, prépayée) : l'émission d'une carte au profit d'un titulaire unique nommément désigné, la délivrance d'une invitation d'installation par e-mail et la liaison de la carte au compte d'appareil du titulaire ;
• pour l'inscription web sans app (cartes standard uniquement) : la création d'une carte et d'un pass Wallet natif depuis une page web, sans que la Personne concernée installe l'app grand public, ainsi que le nom, l'adresse e-mail et le marqueur de consentement marketing facultatifs que le formulaire d'inscription peut recueillir.

3.3 Nature du traitement : traitement automatisé effectué sur l'infrastructure informatique du Sous-traitant et sur celle de ses Sous-traitants ultérieurs autorisés.

3.4 Finalités : exécution du contrat entre le Commerce et ses propres clients dans le cadre du programme de fidélité ; respect des obligations légales du Commerce en tant que Responsable du traitement ; sécurité des systèmes d'information et prévention de la fraude sur les tampons, les récompenses et les soldes ; livraison des cartes personnelles aux personnes spécifiques désignées par le Responsable du traitement et restriction de chacune de ces cartes au compte d'appareil du titulaire ; et, pour l'inscription web sans app, création d'une carte au profit d'une Personne concernée qui n'a pas installé l'app.

3.5 Durée : le présent DPA est en vigueur pendant toute la durée de l'abonnement du Commerce au Service. Les obligations des articles 9 (Restitution et suppression) et 13 (Confidentialité) survivent à la résiliation.

4. Catégories de Personnes concernées et de Données personnelles

4.1 Catégories de Personnes concernées : les clients du Commerce titulaires d'une carte de fidélité de l'un des programmes du Commerce, que ce soit dans l'app grand public TesserApp ou uniquement dans un Wallet natif.

4.2 Catégories de Données personnelles traitées (Annexe B) :

• identifiants d'installation anonymes (jetons aléatoires de 256 bits, non liés à l'identité d'une personne, conservés par le Sous-traitant uniquement sous forme d'empreinte cryptographique) ;
• identifiants des cartes de fidélité (UUID opaques) et numéros de série des cartes ;
• métadonnées de transaction (attributions de tampons, échanges de récompenses, annulations, variations du solde de points ou de crédit ; date, heure et établissement du Commerce où l'opération a eu lieu ; le montant ou le nombre de tampons demandés ; et, pour une annulation, le motif en texte libre rédigé par le Commerce) ;
• identifiants de pass Apple Wallet / Google Wallet, jetons de mise à jour du pass, identifiant attribué par le système d'exploitation à la bibliothèque de pass de l'appareil, et jetons push associés ;
• jetons de notification push émis par Apple (APNs) ou Google (FCM), enregistrés pour l'installation de l'app elle-même ;
• langue système de l'appareil, plateforme (iOS ou Android) et version de l'app ;
• adresses IP et chaînes user-agent, enregistrées dans les journaux d'audit et d'accès à des fins de sécurité. Contrairement à ce qu'indiquait la version 1.0 du présent DPA, elles ne sont pas traitées de manière transitoire : elles sont conservées comme décrit à l'Annexe B, section B.2 ;
• coordonnées GPS, exclusivement lorsque la Personne concernée a activé la fonctionnalité de découverte des commerces à proximité ou consulte le catalogue trié par distance, et pour la seule durée de cette requête. Les coordonnées ne sont pas conservées, ni par le Sous-traitant ni sur l'appareil ;
• adresse e-mail de la Personne concernée, lorsqu'elle la fournit volontairement au Sous-traitant (demandes d'exercice des droits RGPD, contacts avec le support) ;
• rapports techniques d'erreur et de plantage, qui portent le modèle de l'appareil, la version du système d'exploitation et la version de l'app, et peuvent contenir l'identifiant technique d'une carte ou d'un programme impliqués dans l'erreur. Ils sont configurés pour ne pas collecter de données identifiant l'utilisateur et pour ne pas joindre l'adresse IP.

4.2 bis — Cartes personnelles (privée, remise, accès, prépayée) : pour les quatre types de carte personnelle, et non seulement pour les programmes privés :

• le nom et l'adresse e-mail du titulaire, tous deux obligatoires, fournis par le Responsable du traitement lors de la création de la carte et traités afin d'émettre la carte, d'envoyer une invitation d'installation par e-mail, d'imprimer les coordonnées du titulaire sur la carte et sur le pass Wallet et de les afficher au personnel du Commerce lors du scan de la carte ;
• une référence externe (external_ref) — l'identifiant que le Responsable du traitement utilise déjà pour cette personne physique dans ses propres systèmes, par exemple un numéro d'employé ou d'adhérent — lorsque le Responsable du traitement la renseigne via l'API d'intégration ou le connecteur MCP ;
• une référence pseudonyme de liaison au compte d'appareil (un identifiant opaque dérivé du compte iCloud ou Google du titulaire, et non de son nom ou de son adresse e-mail), traitée uniquement pour garantir que la carte demeure sur le compte du titulaire.

Le Responsable du traitement garantit disposer d'une base légale et, lorsque cela est requis, du consentement de la Personne concernée pour fournir ces données ; le Sous-traitant ne les traite que sur instruction documentée du Responsable du traitement.

4.2 ter — Inscription web sans app (cartes standard uniquement) : lorsqu'une Personne concernée obtient une carte standard en s'inscrivant depuis une page web et en l'ajoutant directement à Apple Wallet ou Google Wallet, sans installer l'app grand public, le formulaire d'inscription peut recueillir :

• un nom facultatif et une adresse e-mail facultative. S'ils restent vides, la carte est créée de façon anonyme, exactement comme une carte activée dans l'app ; s'ils sont renseignés, ils sont associés à la carte et traités pour le compte du Responsable du traitement comme au §4.2 bis ;
• un marqueur de consentement marketing, composé de la date et de la source du recueil. À ce jour, il ne s'agit que d'un champ stocké : aucun message promotionnel n'est envoyé sur son fondement, ni par le Sous-traitant ni par le Responsable du traitement au travers des systèmes du Sous-traitant.

L'inscription web sans app n'est disponible que pour les programmes standard (à tampons). La page d'inscription que radioBros publie elle-même ne demande aucun de ces champs ; ils restent à la disposition d'un Responsable du traitement qui intègre la fonctionnalité à ses propres outils.

4.3 Données NON traitées : adresse postale de la Personne concernée ; numéro de téléphone de la Personne concernée ; données de paiement de la Personne concernée (le Service ne traite pas les paiements du client au Commerce) ; historique de navigation ; données biométriques ; identifiants publicitaires ; catégories particulières de données au sens de l'art. 9 du RGPD ; données relatives aux condamnations pénales au sens de l'art. 10 du RGPD ; données de mineurs de moins de 16 ans (le Service ne s'adresse pas à cette tranche d'âge). Le Sous-traitant n'exploite aucun SDK publicitaire, d'attribution ou d'analyse et ne construit aucun profil comportemental.

Le traitement d'un nom et d'une adresse e-mail dépend de la voie par laquelle la carte a été obtenue, et non du seul type de carte. La version 1.0 du présent DPA indiquait que « pour tous les programmes standard/publics, le nom et l'e-mail demeurent non traités ». Cela n'est plus exact, et la position correcte est la suivante :

Comment la carte a été obtenue	Nom et adresse e-mail
Carte standard ou points activée par la Personne concernée dans l'app (QR code ou catalogue)	Non traités. La carte est anonyme et le demeure
Carte personnelle (privée, remise, accès, prépayée) créée par le Responsable du traitement	Toujours traités — les deux sont obligatoires (§4.2 bis)
Carte standard obtenue par inscription web sans app	Facultatifs — traités uniquement si le formulaire les recueille et si la Personne concernée les renseigne (§4.2 ter)
Carte créée par le Responsable du traitement via l'API d'intégration ou le connecteur MCP	Nom et e-mail comme ci-dessus, plus la référence externe du Responsable du traitement (§4.2 bis)

5. Obligations du Sous-traitant

Le Sous-traitant s'engage à :

5.1 traiter les Données personnelles uniquement sur instructions documentées du Responsable du traitement, y compris en ce qui concerne les transferts de Données personnelles vers un pays tiers ou une organisation internationale, à moins qu'il ne soit tenu d'y procéder en vertu du droit de l'Union ou du droit de l'État membre auquel le Sous-traitant est soumis ; dans ce cas, le Sous-traitant informe le Responsable du traitement de cette obligation juridique avant le traitement, sauf si le droit concerné interdit une telle information pour des motifs importants d'intérêt public ;

5.2 veiller à ce que les personnes autorisées à traiter les Données personnelles s'engagent à respecter la confidentialité ou soient soumises à une obligation légale appropriée de confidentialité ;

5.3 prendre toutes les mesures requises en vertu de l'art. 32 du RGPD, telles que décrites à l'Annexe D du présent DPA ;

5.4 respecter les conditions visées aux paragraphes 2 et 4 de l'art. 28 du RGPD pour recruter des Sous-traitants ultérieurs, comme précisé à l'art. 6 du présent DPA ;

5.5 compte tenu de la nature du traitement, aider le Responsable du traitement par des mesures techniques et organisationnelles appropriées, dans la mesure du possible, à s'acquitter de son obligation de donner suite aux demandes d'exercice des droits de la Personne concernée prévus aux art. 15 à 22 du RGPD ;

5.6 aider le Responsable du traitement à garantir le respect des obligations prévues aux art. 32 à 36 du RGPD, compte tenu de la nature du traitement et des informations à la disposition du Sous-traitant ;

5.7 au choix du Responsable du traitement, supprimer ou renvoyer toutes les Données personnelles à la fin de la prestation des services relatifs au traitement, et détruire les copies existantes, sauf si le droit de l'Union ou le droit de l'État membre exige la conservation des données ;

5.8 mettre à la disposition du Responsable du traitement toutes les informations nécessaires pour démontrer le respect des obligations prévues à l'art. 28 du RGPD et permettre la réalisation d'audits, y compris des inspections, par le Responsable du traitement ou par un autre auditeur qu'il mandate, et contribuer à ces audits ;

5.9 informer immédiatement le Responsable du traitement si, selon lui, une instruction constitue une violation du RGPD ou d'autres dispositions du droit de l'Union ou du droit des États membres relatives à la protection des données.

6. Sous-traitants ultérieurs

6.1 Le Commerce accorde par les présentes au Sous-traitant une autorisation générale de recourir aux Sous-traitants ultérieurs énumérés à l'Annexe A, section A.1 du présent DPA.

6.2 Le Sous-traitant informe le Commerce de tout changement envisagé concernant l'ajout ou le remplacement d'autres Sous-traitants ultérieurs moyennant un préavis d'au moins 30 jours, donnant ainsi au Commerce la possibilité de s'opposer à ces changements.

6.3 En cas d'opposition motivée du Commerce, le Sous-traitant évalue des solutions techniques alternatives. Lorsqu'il n'est pas possible d'éviter le nouveau Sous-traitant ultérieur, le Commerce peut résilier son abonnement sans pénalité, avec effet à la date de mise en service du nouveau Sous-traitant ultérieur.

6.4 Le Sous-traitant conclut avec chaque Sous-traitant ultérieur un contrat écrit contenant des obligations de protection des données équivalentes à celles énoncées dans le présent DPA, en particulier s'agissant des mesures techniques et organisationnelles appropriées, de la confidentialité, de l'assistance au Responsable du traitement et de la coopération avec l'autorité de contrôle.

6.5 Le Sous-traitant demeure responsable envers le Commerce des actes du Sous-traitant ultérieur dans les limites prévues à l'art. 28, par. 4, du RGPD.

6.6 L'Annexe A énumère également, séparément des Sous-traitants ultérieurs, les autres destinataires tiers qui reçoivent des données comme effet direct d'une fonctionnalité du produit sans que ces données transitent par les systèmes du Sous-traitant (section A.2), ainsi que les composants qui sont des installations propres du Sous-traitant sur ses propres domaines et ne constituent donc pas des Sous-traitants ultérieurs (section A.3). Cette distinction reprend celle utilisée au §4 de la Politique de confidentialité.

7. Droits des Personnes concernées

7.1 Compte tenu de la nature du traitement, le Sous-traitant assiste le Responsable du traitement par des mesures techniques et organisationnelles appropriées, dans la mesure du possible, pour l'accomplissement de l'obligation du Responsable du traitement de répondre aux demandes d'exercice des droits des Personnes concernées au titre du chapitre III du RGPD (art. 12-22), et en particulier :

• droit d'accès (art. 15) ;
• droit de rectification (art. 16) ;
• droit à l'effacement (art. 17), mis en œuvre au travers du flux décrit à l'article 9 ci-dessous, dont la première étape est l'effacement immédiat et irréversible des données identifiantes du titulaire ;
• droit à la limitation du traitement (art. 18) ;
• droit à la portabilité des données (art. 20) ;
• droit d'opposition (art. 21) ;
• droit de ne pas faire l'objet d'une décision fondée exclusivement sur un traitement automatisé (art. 22) : le Service n'opère aucun profilage automatisé produisant des effets juridiques à l'égard de la Personne concernée.

7.2 Les demandes reçues directement par le Sous-traitant sont transmises sans délai au Responsable du traitement, sauf si le Sous-traitant est autorisé par écrit par le Responsable du traitement à y répondre directement.

7.3 Ce que le tableau de bord offre réellement à ce jour. La version 1.0 du présent DPA indiquait que le tableau de bord mettait à disposition des outils pour exporter, anonymiser et suspendre les données d'une Personne concernée déterminée. De ces outils, un seul existe. La position exacte est la suivante :

Droit	Comment il s'exerce à ce jour
Effacement d'une Personne concernée déterminée	En libre-service dans le tableau de bord. Sous Paramètres → Données client, le Responsable du traitement peut rechercher une carte par son numéro de série et la supprimer. La suppression retire de la carte le nom, l'adresse e-mail et la référence externe du titulaire
Export des données d'une Personne concernée déterminée	Sur demande, exécuté par le Sous-traitant. Il n'existe pas d'export par Personne concernée dans le tableau de bord. La fonction d'export de données du tableau de bord produit l'archive du compte du Responsable du traitement lui-même, et non le dossier d'une Personne concernée déterminée. Il suffit d'écrire à privacy@tesserapp.eu et le Sous-traitant prépare l'extrait
Rectification des coordonnées d'une Personne concernée déterminée	Sur demande, exécutée par le Sous-traitant, ou par le Responsable du traitement en réémettant la carte
Limitation / suspension d'une Personne concernée déterminée	Sur demande, exécutée par le Sous-traitant. Il n'existe pas de commande de suspension par Personne concernée dans le tableau de bord

7.4 Le Sous-traitant s'engage à étendre les outils en libre-service à l'export et à la limitation par Personne concernée. Tant qu'ils n'existent pas, le présent DPA ne les présente pas comme disponibles, et les demandes visées au §7.3 sont traitées par le Sous-traitant dans les délais de l'Annexe C.

8. Notification de Violation de Données personnelles

8.1 En cas de Violation de Données personnelles dont le Sous-traitant a connaissance, le Sous-traitant notifie l'évènement au Responsable du traitement dans les meilleurs délais et, en tout état de cause, dans les 72 heures suivant la prise de connaissance, en fournissant, dans la mesure du possible, les informations visées à l'art. 33, par. 3, du RGPD et notamment :

• la nature de la violation, les catégories et le nombre approximatif de Personnes concernées ;
• les catégories et le nombre approximatif d'enregistrements de données personnelles concernés ;
• les coordonnées du point de contact pour l'incident ;
• les conséquences probables de la violation ;
• les mesures prises ou proposées pour y faire face et atténuer ses éventuels effets négatifs.

8.2 Lorsque, et dans la mesure où, il n'est pas possible de fournir les informations en même temps, les informations peuvent être communiquées de manière échelonnée sans délai indu supplémentaire.

8.3 Il est entendu qu'il appartient au Responsable du traitement, au titre des art. 33 et 34 du RGPD, de décider s'il notifie la violation à l'autorité de contrôle et la communique aux Personnes concernées.

9. Restitution et suppression des Données personnelles à la résiliation

9.1 Export. À la résiliation de l'abonnement, et en tout état de cause dans les 30 jours suivant celle-ci, le Commerce peut demander au Sous-traitant l'export intégral des Données personnelles dans un format structuré, couramment utilisé et lisible par machine. L'export est produit sous forme d'archive ZIP contenant des fichiers JSON, téléversée sur le stockage objet du Sous-traitant et remise au Commerce sous la forme d'un lien signé valable 48 heures. Les éléments identifiants côté client qu'il n'appartient pas au Commerce de recevoir (empreintes des jetons d'installation, adresses IP) sont anonymisés à l'intérieur de l'archive.

9.2 Suppression. À l'expiration du délai ci-dessus sans demande d'export, ou après achèvement de l'export, le Sous-traitant procède à la suppression des Données personnelles. Le cycle de vie réellement appliqué par le Service est le suivant, et l'affirmation de la version 1.0 selon laquelle les données seraient « définitivement supprimées des systèmes de production dans un délai de 5 jours » est retirée :

• un abonnement suspendu est résilié automatiquement au bout de 60 jours ;
• 150 jours après la résiliation, un avis est envoyé au Commerce indiquant que ses données vont être supprimées ;
• 180 jours après la résiliation, le compte est anonymisé automatiquement. L'anonymisation supprime le nom et l'e-mail de connexion, le mot de passe, le second facteur, les passkeys, les identités sociales, les fiches du personnel, les appareils appairés, les clés d'API, ainsi que le nom, l'adresse e-mail et la référence externe sur chacune des cartes des clients du Commerce ;
• lorsque le Commerce demande la suppression depuis le tableau de bord, la même anonymisation est effectuée 30 jours après la demande, ce délai constituant une fenêtre de grâce durant laquelle la demande peut être annulée ;
• pour une carte individuelle supprimée, les champs identifiants du titulaire sont effacés au moment même de la demande, en même temps que l'identifiant d'installation qui liait la carte à l'appareil du titulaire ; à compter de cet instant la suppression est irréversible et aucun délai de récupération n'existe. Sous 30 jours, une tâche nocturne planifiée supprime les enregistrements dépendants et l'enregistrement de la carte lui-même, sauf si une écriture comptable conservée s'y rapporte : l'enregistrement est alors purgé sur place et il ne subsiste qu'un identifiant nu qui n'identifie personne, retiré en tout état de cause lors de l'anonymisation décrite ci-dessus.

9.3 Données exclues de la suppression. Sont exclues de la suppression, pour la durée strictement nécessaire, les Données personnelles dont la conservation est imposée par des obligations légales pesant sur radioBros. Cela concerne les factures propres du Sous-traitant adressées au Commerce, et non les données des Personnes concernées, et la durée de conservation est de 10 ans :

• L'art. 2220 du Code civil italien impose de conserver pendant 10 ans les factures — celles reçues et les copies de celles émises — ainsi que les écritures comptables qui s'y rapportent. C'est l'obligation effectivement appliquée, et c'est la durée mentionnée dans la Politique de confidentialité et dans les Conditions de Service.
• La législation fiscale italienne applicable (DPR 633/1972 ; D.Lgs. 127/2015) fixe un minimum plus court, de 7 ans, que la durée ci-dessus satisfait déjà.

Ces données sont conservées sous garde séparée, avec un accès restreint et journalisé, et ne font l'objet d'aucun autre traitement que l'exécution de l'obligation.

9.4 Sur demande écrite du Commerce, le Sous-traitant délivre une attestation formelle de suppression effectuée.

10. Transferts internationaux de données

10.1 Le Sous-traitant traite les Données personnelles sur ses propres systèmes exclusivement sur une infrastructure située dans l'Espace économique européen. Les systèmes de production sont hébergés en Allemagne.

10.2 Certains Sous-traitants ultérieurs énumérés à l'Annexe A peuvent avoir leur siège ou des activités aux États-Unis (en particulier Stripe, Apple, Google, Cloudflare). Les transferts de Données personnelles vers ces parties sont effectués sur la base des Clauses contractuelles types adoptées par la Commission européenne par la décision 2021/914/UE, complétées par des mesures supplémentaires lorsque cela est nécessaire au regard de l'arrêt de la CJUE C-311/18 (Schrems II).

10.2 bis — Transferts qui ne transitent pas par les systèmes du Sous-traitant. Certains destinataires énumérés à l'Annexe A, section A.2, sont contactés directement par le navigateur du Commerce ou par l'appareil de la Personne concernée, comme effet direct d'une fonctionnalité du produit. Pour ceux-ci, le lieu du traitement est celui du destinataire et le Sous-traitant ne figure pas dans la chaîne de transmission :

• Overpass (overpass-api.de, un service public du projet OpenStreetMap) : sur iOS, l'appareil de la Personne concernée lui envoie les coordonnées GPS lorsque la fonctionnalité des commerces à proximité est utilisée ;
• LocationIQ (Unwired Labs) : le navigateur du Commerce lui envoie le texte de l'adresse saisi dans le tableau de bord ;
• Google Fonts et Stripe.js : chargés par le tableau de bord sur chaque page, de sorte que l'adresse IP et le type de navigateur de celui qui ouvre le tableau de bord parviennent respectivement à Google et à Stripe.

10.3 Aucun transfert n'est effectué vers des pays tiers en dehors du cadre des Clauses contractuelles types ou d'une décision d'adéquation de la Commission, à l'exception des appels directs depuis le navigateur et depuis l'appareil visés au §10.2 bis, dont la base du transfert est indiquée à l'Annexe A.

11. Mesures techniques et organisationnelles

Les mesures techniques et organisationnelles adoptées par le Sous-traitant au titre de l'art. 32 du RGPD sont décrites à l'Annexe D du présent DPA, qui en fait partie intégrante. L'Annexe D distingue les mesures déjà en place de celles que le Sous-traitant s'engage à mettre en place. Ces mesures sont soumises à une mise à jour périodique reflétant l'état de l'art ; aucune mise à jour ne peut entraîner une réduction du niveau de sécurité garanti.

12. Audit

12.1 Le Sous-traitant met à la disposition du Responsable du traitement, sur demande écrite, les informations nécessaires pour démontrer le respect des obligations découlant de l'art. 28 du RGPD et du présent DPA.

12.2 Le Responsable du traitement peut demander, une fois par année civile, la réalisation d'un audit, à exécuter moyennant un préavis écrit d'au moins 30 jours, pendant les heures ouvrables, dans les locaux du Sous-traitant, selon des modalités qui n'interfèrent pas avec la continuité opérationnelle du Service et respectent les mesures de sécurité en vigueur.

12.3 Les coûts directs de l'audit sont à la charge du Responsable du traitement, sauf si l'audit révèle des manquements significatifs au présent DPA imputables au Sous-traitant, auquel cas les coûts sont à la charge du Sous-traitant.

12.4 Le Sous-traitant ne détient à ce jour aucune certification de sécurité délivrée par un tiers (aucun rapport SOC 2, aucun certificat ISO 27001). S'il en obtenait une, il pourrait proposer, en lieu et place de l'audit sur site, la production du rapport d'auditeur indépendant correspondant, accompagné d'une documentation équivalente.

13. Confidentialité

13.1 Les Parties s'engagent à traiter comme strictement confidentielles toutes les informations acquises dans l'exécution du présent DPA, à l'exception des informations relevant du domaine public ou dont la divulgation est requise par la loi ou par décision de l'autorité.

13.2 L'obligation de confidentialité s'étend aux salariés, collaborateurs et Sous-traitants ultérieurs des Parties et survit à la résiliation du présent DPA.

14. Responsabilité et indemnisation

14.1 Chaque Partie est responsable des dommages causés par son traitement enfreignant le RGPD, dans les limites et selon les modalités prévues à l'art. 82 du RGPD.

14.2 Dans les rapports internes entre les Parties, la responsabilité de radioBros envers le Commerce pour le traitement des Données personnelles est régie par la clause de limitation de responsabilité figurant dans les Conditions générales d'utilisation, sous réserve des cas de faute dolosive ou de faute lourde et sans préjudice de la responsabilité envers la Personne concernée au titre du RGPD.

14.3 Le Commerce garantit et tient indemne radioBros de toute réclamation découlant du manquement du Commerce à ses propres obligations en tant que Responsable du traitement au titre du RGPD (en particulier : information correcte des Personnes concernées au titre des art. 13-14 du RGPD ; base légale appropriée du traitement ; exactitude des instructions données au Sous-traitant).

15. Durée, modifications et dispositions finales

15.1 Durée. Le présent DPA est effectif à compter de la date d'acceptation par le Commerce à l'inscription (via une case à cocher dédiée) et pendant toute la durée de l'abonnement au Service. Les obligations de restitution/suppression (art. 9) et de confidentialité (art. 13) survivent à la résiliation.

15.2 Modifications. Les modifications substantielles du présent DPA seront communiquées au Commerce avec un préavis d'au moins 30 jours par e-mail à l'adresse enregistrée sur le compte et via un bandeau dédié sur le tableau de bord. Le Commerce sera tenu de ré-accepter la nouvelle version à la connexion suivante. Le défaut d'acceptation ouvre droit à la résiliation de l'abonnement sans pénalité.

15.2 bis — Entrée en vigueur de la version 1.1. La version 1.1 du présent DPA entre en vigueur à la date de publication indiquée en tête du présent document, sans attendre le préavis de 30 jours prévu au §15.2. La raison tient à la nature de cette révision : la version 1.1 n'impose au Responsable du traitement aucune obligation nouvelle et ne réduit aucune garantie des Personnes concernées ; elle corrige des affirmations inexactes de la version 1.0, élargit les informations fournies et retire des engagements qu'aucun processus du Service n'a jamais exécutés — dont la suppression « dans les cinq jours » visée au §9.2, que les systèmes n'opéraient pas. En plusieurs endroits, le texte qui en résulte est moins favorable au Sous-traitant et plus favorable à celui qui le lit, parce qu'il cesse de surestimer la confidentialité offerte et de promettre des suppressions qui n'avaient pas lieu. Différer de 30 jours une correction de cette nature reviendrait à maintenir en vigueur pendant 30 jours encore un texte que l'on sait inexact : le préavis du §15.2 existe pour protéger le Commerçant des modifications qui altèrent les obligations, non pour retarder la description véridique d'un traitement déjà en cours. Ce raisonnement ne s'étend pas au §6.2, que la présente disposition laisse entièrement intact. La nouvelle Annexe A énumère des destinataires que la version 1.0 ne mentionnait pas : la plupart participaient déjà au traitement et sont simplement consignés. L'un d'eux au moins, toutefois — Unwired Labs (LocationIQ), auquel le Sous-traitant recourt depuis juin 2026 pour l'autocomplétion des adresses dans le tableau de bord du Commerçant — a bel et bien été ajouté après la version 1.0, et la situation des autres points indiqués à l'Annexe A, section A.4 n'est pas encore établie. Pour ceux-là, le §6.2 s'applique intégralement : le préavis de 30 jours et le droit d'opposition du Commerçant sont donnés comme cet article l'exige, et la section A.4 en prend acte.

Le §15.2 demeure intact. Le §15.2 conserve son plein effet pour toute modification future du présent DPA. Le §15.2 bis est une dérogation transitoire unique, limitée à l'entrée en vigueur de la version 1.1 : il ne réduit, ne réinterprète ni ne suspend le préavis de 30 jours, l'obligation de réacceptation ou la faculté de résiliation sans pénalité que le §15.2 reconnaît au Commerçant, et il en va de même du §6.2 quant à l'ajout effectif d'un nouveau Sous-traitant ultérieur. Toute modification ultérieure qui altère les obligations des Parties suit intégralement le §15.2.

Le préavis donné avec la présente publication. À l'entrée en vigueur de la version 1.1 sont donnés : la publication du texte sur cette page, portant en tête sa date et son numéro de version ; une communication par courrier électronique aux Commerçants à l'adresse enregistrée sur le compte ; et la demande d'acceptation de la nouvelle version, qui sera adressée au Commerçant lorsque la fonction correspondante sera disponible — à la date de publication, le Service ne dispose pas de mécanisme de réacceptation, et la présente disposition n'en promet aucun avant cette date. Aucune communication n'est adressée aux Personnes concernées par l'intermédiaire de l'application : l'application n'est pas un canal de communications juridiques. Le Commerçant qui ne souhaite pas accepter la version 1.1 conserve la faculté de résilier sans pénalité prévue au §15.2.

15.3 Langue. La version italienne du présent DPA est la version officielle et prévaut sur les traductions en cas de divergence.

15.4 Droit applicable et juridiction. Le présent DPA est régi par le droit italien. Tout litige relève de la compétence exclusive du Tribunal de Rome.

15.5 Traçabilité de l'acceptation. L'acceptation du DPA est tracée par le Sous-traitant par l'enregistrement de : raison sociale du Commerce, e-mail de l'utilisateur qui a accepté, adresse IP, horodatage et version du DPA acceptée. Ces données constituent une preuve d'acceptation au titre des art. 20 et 21 du Décret législatif italien 82/2005 (Code de l'administration numérique).

---

Annexe A — Sous-traitants ultérieurs, autres destinataires et infrastructure propre

La présente annexe reprend la même répartition en trois volets que le §4 de la Politique de confidentialité, afin que les deux documents puissent être lus côte à côte.

A.1 Sous-traitants ultérieurs (art. 28 du RGPD)

Prestataires qui traitent des Données personnelles pour le compte du Sous-traitant, en vertu d'un accord au titre de l'art. 28. La colonne « Données de qui » est déterminante : certains de ces prestataires ne touchent que les données propres du Commerce et jamais celles des Personnes concernées.

Sous-traitant ultérieur	Siège et lieu du traitement	Rôle	Données de qui, et lesquelles	Base du transfert
Contabo GmbH	Allemagne	Hébergement VPS de tous les systèmes de production : base de données, application, files de traitement, cache, index de recherche du catalogue et les dumps de base de données décrits au point D.3	Données des Personnes concernées — toutes les catégories relevant du Service	Traitement dans l'UE
Stripe Payments Europe Ltd.	Irlande (groupe avec activités aux États-Unis)	Traitement des paiements de l'abonnement du Commerce ; émission des factures	Données du Commerce uniquement — données de paiement et fiscales. Pas de données des Personnes concernées	SCC 2021/914/UE
Cloudflare, Inc.	États-Unis — buckets R2 configurés en région UE	Stockage objet pour les images de programme et de carte d'accès téléversées par le Commerce et pour les archives d'export RGPD demandées par le Commerce ; CDN pour les ressources statiques. Aucune sauvegarde de base de données n'y est conservée (voir D.3)	Données du Commerce, ainsi que données des Personnes concernées dans la mesure où elles figurent dans une archive d'export demandée par le Commerce	SCC 2021/914/UE
Apple Inc.	États-Unis	Livraison des pass Apple Wallet et des notifications push (APNs) ; provisionnement du Pass Type ID et du certificat de signature propres au Commerce via l'API App Store Connect	Données des Personnes concernées — jetons push, identifiants de pass et le contenu du pass lui-même, qui pour les cartes personnelles comprend le nom et l'e-mail du titulaire. Les appels à App Store Connect ne portent que des identifiants du Commerce	SCC 2021/914/UE
Google LLC	États-Unis	Livraison des pass Google Wallet (API Google Wallet) et des notifications push (Firebase Cloud Messaging)	Données des Personnes concernées — comme pour Apple	SCC 2021/914/UE
Exploitant du serveur de messagerie transactionnelle mail.tesserapp.eu	[À COMPLÉTER — voir A.4]	Envoi des e-mails transactionnels par SMTP : invitations d'installation de carte, alertes d'activité, avis de service	Données des Personnes concernées — adresse e-mail du destinataire et contenu du message ; ainsi que données du Commerce	[À COMPLÉTER — voir A.4]
Unwired Labs (LocationIQ)	[À COMPLÉTER — voir A.4]	Autocomplétion d'adresse dans le tableau de bord du Commerce. Engagé par le Sous-traitant, mais l'appel part directement du navigateur du Commerce avec une clé publiable et ne transite pas par les systèmes du Sous-traitant — voir A.2 et §10.2 bis	Données du Commerce uniquement — le texte de l'adresse saisi et l'adresse IP du navigateur. Pas de données des Personnes concernées	[À COMPLÉTER — voir A.4]
Intermédiaire de facturation électronique vers le Sistema di Interscambio italien (SdI)	Italie	Transmission des factures électroniques propres du Sous-traitant. Conditionnel : le Service prend en charge un intermédiaire externe, mais la configuration par défaut ne transmet rien à un tel intermédiaire. Savoir si la production en utilise un à ce jour est [À COMPLÉTER — voir A.4]	Données du Commerce uniquement — données de facturation. Pas de données des Personnes concernées	Traitement dans l'UE

Supprimés en version 1.1. Deux prestataires nommés à l'Annexe A de la version 1.0 ne sont pas, et n'ont jamais été, engagés, et ont été supprimés :

• Resend — jamais utilisé. Il n'existe nulle part dans le Service ni dépendance, ni point d'appel, ni configuration le concernant. Les e-mails transactionnels sont envoyés par SMTP via mail.tesserapp.eu. Une colonne de base de données nommée resend_message_id subsiste comme appellation héritée et est remplie avec l'identifiant de message renvoyé par le serveur SMTP.
• FontAwesome, Inc. — ne reçoit rien. cdn.woptima.com est le CDN d'icônes propre au Sous-traitant, sous sa propre licence (voir A.3) ; les icônes du présent site sont compilées dans les pages publiées.

A.2 Autres destinataires tiers

Services qui reçoivent des données comme effet direct d'une fonctionnalité du produit, sans que ces données transitent par les systèmes du Sous-traitant. Ce ne sont pas des Sous-traitants ultérieurs, car le Sous-traitant ne figure pas dans la chaîne de transmission.

Destinataire	Ce qu'il reçoit, et quand
Overpass — overpass-api.de, un service public du projet OpenStreetMap	Sur iOS, lorsque la Personne concernée utilise la fonctionnalité des commerces à proximité, l'appareil envoie à ce point d'accès public les coordonnées GPS de la Personne concernée, en pleine précision et non arrondies, afin de rechercher des points d'intérêt dans un rayon de 50 mètres. Rien d'autre n'est envoyé : aucun identifiant, aucune carte, aucune donnée de l'app. Sur Android, le même client existe dans l'app, mais ce chemin de code n'est pas actuellement atteint
LocationIQ (Unwired Labs)	Lorsque le Commerce saisit une adresse dans le tableau de bord, le navigateur envoie à LocationIQ le texte saisi (et, dans les formulaires d'établissement, le code pays). Ni l'identité du Commerce ni aucune donnée de session ne sont envoyées. L'adresse IP du navigateur est implicite à chaque appel. La clé publiable est incluse dans le bundle du tableau de bord et restreinte par domaine
Google LLC (Google Fonts)	Les polices du tableau de bord sont chargées depuis fonts.googleapis.com et fonts.gstatic.com sur chaque page : Google reçoit donc l'adresse IP et le type de navigateur de celui qui ouvre le tableau de bord
Stripe, Inc. (Stripe.js)	La bibliothèque de paiement est chargée sur chaque page du tableau de bord, et non seulement sur les pages de facturation : Stripe reçoit donc l'adresse IP et les données techniques du navigateur même lorsqu'aucun paiement n'est en cours. Les données de carte sont saisies dans des champs hébergés par Stripe et ne transitent jamais par les systèmes du Sous-traitant
Apple Inc. / Google LLC (Se connecter avec Apple / avec Google)	Uniquement si le Commerce choisit de se connecter avec Apple ou Google, et uniquement pour l'opération de connexion
Apple Inc. / Google LLC (sauvegarde de l'appareil, Wallets natifs)	En leur qualité de fournisseurs du compte de la Personne concernée elle-même : la base de données locale de l'app grand public, y compris le nom et l'e-mail du titulaire sur les cartes personnelles, est intégrée à la sauvegarde du compte iCloud ou Google de la Personne concernée

A.3 Infrastructure propre du Sous-traitant

Composants qui peuvent ressembler à des services tiers mais qui sont des installations propres du Sous-traitant, sur ses propres domaines, sans aucun partage de données avec l'éditeur du logiciel. Ce ne sont pas des Sous-traitants ultérieurs.

Composant	Logiciel	Rôle
glitchtip.radiobros.com	GlitchTip (auto-hébergé)	Collecte des rapports techniques d'erreur et de plantage des apps. Configuré pour ne pas collecter de données identifiant l'utilisateur, ne pas suivre les sessions et ne pas joindre d'adresses IP
helpdesk.radiobros.com	Zammad (auto-hébergé)	Système d'assistance pour les tickets du Commerce. Reçoit l'e-mail de contact et la dénomination du Commerce, ainsi que le titre, le corps et les pièces jointes de chaque ticket
mail.tesserapp.eu	SMTP	Domaine de messagerie transactionnelle propre au Sous-traitant. L'exploitant du serveur sous-jacent est indiqué au point A.1
cdn.woptima.com	CDN statique sous licence propre du Sous-traitant	Diffusion des icônes d'interface, aussi bien vers le navigateur que vers les serveurs du Sous-traitant lorsqu'ils composent un pass Wallet. Aucune donnée personnelle. FontAwesome, Inc. ne reçoit rien
adminizer.radiobros.com	Authentik (auto-hébergé)	Fournisseur d'identité contrôlant l'accès administratif et machine-à-machine aux systèmes de production
Collecte centralisée des journaux applicatifs	Loki (auto-hébergé)	Diagnostic et sécurité. Lorsqu'elle est activée, les journaux peuvent contenir des adresses IP et le contexte technique d'une requête
Index de recherche du catalogue	Meilisearch (auto-hébergé, sur le serveur de production)	Recherche sur les programmes publics. Contient les données de programme du Commerce, et non des données des Personnes concernées : aucun nom, aucune adresse e-mail, aucune carte

A.4 Points ouverts de la présente annexe

Les éléments suivants ne se déduisent pas de la configuration du Service et sont déclarés ici comme ouverts plutôt que devinés. Le Sous-traitant les complétera dans la prochaine version et, si l'un d'eux devait ajouter un Sous-traitant ultérieur, respectera le préavis de 30 jours exigé par le §6.2 :

1. Qui exploite le serveur de messagerie mail.tesserapp.eu, son lieu de traitement et sa base de transfert.
2. Le lieu de traitement et la base de transfert de LocationIQ (Unwired Labs).
3. L'hébergeur des sous-domaines *.radiobros.com propres au Sous-traitant, énumérés au point A.3.
4. Si la production transmet à ce jour ses factures électroniques via un intermédiaire SdI externe.

La liste courante est tenue dans la présente annexe. La version 1.0 renvoyait le Commerce à une page « Confidentialité → Sous-traitants » du tableau de bord ; cette page n'existe pas, et la présente annexe constitue la liste faisant foi.

Annexe B — Catégories de données et durées de conservation

La version 1.0 de la présente annexe citait des durées de conservation qu'aucun processus n'appliquait. Cette version sépare les deux cas, au motif qu'il vaut mieux décrire le comportement réel du Service que publier une échéance que rien n'applique.

B.1 Durées appliquées par un processus automatisé

Catégorie	Conservation	Base juridique
Enregistrements de livraison des webhooks envoyés au Commerce (pour les cartes personnelles, ces charges utiles contiennent le nom et l'e-mail du titulaire)	30 jours, supprimés automatiquement par un balayage planifié. Lorsqu'une carte est supprimée, le nom, l'e-mail et la référence externe sont immédiatement masqués dans les charges utiles déjà stockées ; l'enregistrement technique de l'appel (événement, résultat, date) subsiste jusqu'à l'expiration des 30 jours	Intérêt légitime à la fiabilité de l'intégration
Cycle de vie de l'abonnement du Commerce	Un abonnement suspendu est résilié au bout de 60 jours ; 150 jours après la résiliation, un avis de suppression est envoyé ; 180 jours après la résiliation, le compte est anonymisé, ce qui retire le nom, l'e-mail et la référence externe sur chacune des cartes des clients du Commerce	Art. 28, par. 3, point g), du RGPD ; limitation de la conservation
Suppression demandée par le Commerce depuis le tableau de bord	Exécutée 30 jours après la demande, avec la même anonymisation. La fenêtre constitue un délai de grâce durant lequel la demande peut être annulée	Instruction du Responsable du traitement
Carte individuelle supprimée par la Personne concernée ou par le Commerce	Champs identifiants effacés immédiatement et irréversiblement ; aucun délai de récupération. Les enregistrements dépendants et, lorsqu'aucune écriture comptable conservée ne s'y rapporte, l'enregistrement de la carte lui-même sont supprimés sous 30 jours ; voir B.2	Exécution du contrat du programme de fidélité
Intentions de paiement non abouties pour de nouveaux établissements	24 heures, puis supprimées par un balayage quotidien	Exécution du contrat (données du Commerce uniquement)

B.2 Catégories sans expiration automatisée

Pour les catégories suivantes, aucun processus planifié ne supprime les données. Elles sont retirées sur demande au titre du §7.3 et, en tout état de cause, par l'anonymisation prévue au point B.1.

Catégorie	Ce qui se produit réellement
Identifiants des cartes de fidélité et enregistrements de cartes dans un état « supprimé »	L'enregistrement est conservé indéfiniment dans un état « supprimé ». Lors de la suppression d'une carte, un champ d'horodatage pour une purge définitive est écrit, mais rien ne le lit : la purge définitive est une opération administrative manuelle. La « suppression dans un délai de 5 jours » de la version 1.0 est retirée
Métadonnées de transaction (tampons, récompenses, annulations, variations de solde)	Conservées comme registre de l'activité du Commerce et non supprimées avec une carte individuelle. Les références au titulaire sont retirées lorsque ses données sont effacées. La mention de la version 1.0 (« 24 mois actifs, puis archivées avec des références pseudonymisées ») est retirée : aucun traitement d'archivage de ce type n'existe
Événements d'audit et journaux d'accès, y compris adresse IP et user-agent	Conservés sans échéance prédéfinie. Il n'existe pour eux aucun traitement de conservation, ni de table distincte de journaux d'accès. Ils constituent le registre de ce qui a été fait, y compris la preuve qu'un effacement a été réalisé. La mention de la version 1.0 (« adresses IP mises à zéro lors de la suppression définitive de la carte de la Personne concernée ») est retirée
Enregistrements des e-mails sortants (adresse du destinataire et contenu des variables du modèle)	Conservés sans expiration automatique : rien ne les supprime. Les « 30 jours à compter de la clôture de la procédure » de la version 1.0 sont retirés
Adresse e-mail de la Personne concernée fournie volontairement au Sous-traitant	Conservée le temps nécessaire au traitement de la demande et à la preuve de son issue. Aucune expiration automatique
Annonces du Commerce envoyées aux titulaires d'un programme (titre, texte, image, lien, nombre d'appareils atteints)	Conservées comme registre des communications du Commerce. Aucune expiration automatique
Enregistrements d'installation pour les notifications (empreinte du jeton d'installation, jeton push, langue, plateforme, version de l'app)	Conservés jusqu'à demande de suppression. Aucune expiration automatique
Identifiants et jetons de mise à jour des pass Apple / Google Wallet	Conservés jusqu'à ce que la Personne concernée retire le pass du Wallet natif, ou que la carte soit supprimée
Coordonnées GPS	Non conservées du tout. Elles voyagent dans la seule requête qui les utilise et ne sont stockées ni par le Sous-traitant ni sur l'appareil
Archives d'export RGPD demandées par le Commerce	Le ZIP est téléversé sur le stockage objet et remis via un lien signé de 48 heures. L'archive demeure ensuite dans le bucket jusqu'à retrait manuel : la règle de cycle de vie à 7 jours évoquée dans le code n'est pas configurée. C'est l'expiration du lien signé, et non un traitement de suppression, qui limite l'exposition
Tickets d'assistance dans le helpdesk du Sous-traitant	Conservés sans expiration automatique
Rapports techniques d'erreur et de plantage	Conservés dans le système de diagnostic propre du Sous-traitant le temps nécessaire à la correction du défaut
Factures de l'abonnement du Commerce	Voir §9.3 : 10 ans au titre de l'art. 2220 du Code civil italien, qui mentionne expressément les factures ; la législation fiscale applicable en exige au moins 7, que cette durée satisfait déjà. Données du Commerce, non des Personnes concernées

Annexe C — Droits des Personnes concernées et modalités d'exercice

Le Commerce est le premier destinataire des demandes d'exercice des droits RGPD de ses propres clients. radioBros assiste le Commerce en fournissant :

• un outil de données client dans le tableau de bord (Paramètres → Données client) qui recherche une carte par numéro de série et la supprime, en retirant le nom, l'adresse e-mail et la référence externe du titulaire. C'est à ce jour la seule action par Personne concernée disponible en libre-service ; l'export, la rectification et la limitation sont effectués par le Sous-traitant sur demande, comme indiqué au §7.3 ;
• la possibilité de demander directement à radioBros, à l'adresse privacy@tesserapp.eu, l'exercice des droits, qui sera transmis sans délai au Commerce ou exécuté sur instruction de celui-ci ;
• une piste d'audit des opérations significatives, tenue par le Sous-traitant et mise à la disposition du Commerce sur demande. La version 1.0 la décrivait comme « accessible à tout moment par le Commerce » ; à ce jour il n'en existe aucune vue dans le tableau de bord, et le Sous-traitant fournit l'extrait pertinent sur demande.

Délais indicatifs de réponse (maximums au titre de l'art. 12 du RGPD) : 30 jours à compter de la demande, prorogeables de 60 jours supplémentaires en cas de complexité, avec information de la Personne concernée.

Annexe D — Mesures techniques et organisationnelles (art. 32 du RGPD)

Chaque mesure ci-dessous est signalée [en place] lorsqu'elle est mise en œuvre dans le Service à ce jour, ou [engagement] lorsque le Sous-traitant s'y engage sans pouvoir encore l'attester. La version 1.0 présentait comme des faits plusieurs mesures que les systèmes n'implémentaient pas ; elles sont ici corrigées.

D.1 Confidentialité

• [en place] Chiffrement en transit par TLS 1.2 ou supérieur sur tous les points d'accès exposés.
• [en place] Chiffrement au repos en AES-256 (SSE) des objets stockés sur Cloudflare R2. Les secrets applicatifs — certificats de pass Wallet, secrets TOTP — sont chiffrés en AES-256-GCM sous une clé distincte.
• [en place] Hachage argon2id, avec des paramètres conformes aux recommandations de l'OWASP, pour les mots de passe des comptes Commerce, les codes PIN du personnel et les codes de récupération. Aucun mot de passe n'est jamais stocké en clair.
• [en place] Hachage SHA-256 pour les jetons aléatoires à haute entropie — cookies de session, jetons d'installation, jetons d'invitation, clés d'API. La version 1.0 indiquait que les jetons d'authentification étaient hachés en argon2id ; cela est inexact, et le choix est délibéré : pour un jeton aléatoire de 256 bits, l'espace de recherche rend déjà une attaque par force brute irréalisable, de sorte qu'un hachage volontairement lent n'apporte rien et coûte une recherche à chaque requête.
• [en place] Certains jetons sont stockés tels qu'émis, sans hachage, parce qu'ils doivent être rejoués à l'identique auprès d'un tiers ou reconnus lors d'un appel entrant : les jetons de notification push (APNs, FCM), le jeton d'authentification du pass Wallet et les jetons de revendication à usage unique de l'inscription sans app. Leur exposition est limitée par leur portée — un jeton push est dépourvu de sens en dehors de l'app du Service ; un jeton d'authentification de pass n'autorise que les mises à jour de ce seul pass — et par les contrôles d'accès du point D.2.
• [en place] Séparation des environnements (production, préproduction, développement) avec des identifiants distincts et aucun accès aux données de production depuis les environnements hors production.

D.2 Intégrité

• [en place] Contrôle d'accès fondé sur les rôles sur l'infrastructure de production, l'accès administratif et machine-à-machine étant contrôlé par le fournisseur d'identité propre du Sous-traitant (A.3).
• [en place] Journal d'audit de chaque opération administrative et de chaque opération significative côté Commerce, écrit dans une table dédiée à laquelle l'application ne fait qu'ajouter.
• [en place] Migrations de schéma de base de données versionnées, suivies par un journal d'empreintes qui détecte la modification d'une migration.
• [en place] Limitation de débit sur les points d'accès d'authentification et sur les API publiques.

D.3 Disponibilité et résilience

La version 1.0 décrivait des « sauvegardes automatiques quotidiennes de la base de données avec Point-In-Time Recovery (PITR) par streaming WAL (pgBackRest) ». Rien de cela n'est mis en œuvre. Ce que le Service fait réellement :

• [en place] Dumps logiques horaires de la base de données (pg_dump, format custom compressé), réalisés par un conteneur dédié qui se connecte directement à PostgreSQL.
• [en place] Vérification en trois étapes de chaque dump avant publication : la commande de dump doit se terminer avec succès ; le fichier doit dépasser une taille minimale, ce qui intercepte le mode de défaillance « connecté, authentifié, schéma vide dumpé » ; et la table des matières du dump doit contenir une table sentinelle, ce qui prouve que des données réelles s'y trouvent. Seul un dump satisfaisant aux trois contrôles est publié, et seul un succès vérifié peut déclencher l'élagage des dumps plus anciens — ainsi, une série d'échecs ne peut jamais éroder les bonnes sauvegardes restantes.
• [en place] Rétention plate des 168 dumps les plus récents, conservés sur le système de fichiers du serveur de production. À l'intervalle horaire, cela représente environ une semaine d'historique. Il n'existe aucune promotion par paliers.
• Non mis en œuvre, énoncé sans détour : les dumps ne sont pas chiffrés par le processus de sauvegarde lui-même ; il n'y a aucun archivage des WAL et donc aucune restauration à un instant donné — le point de reprise est l'intervalle de sauvegarde ; et les dumps ne sont pas répliqués hors du serveur. Un fichier d'état lisible par machine consigne le résultat de la dernière exécution.
• [engagement] Chiffrement des dumps au repos et copie hors du serveur.
• [engagement] Exercices de restauration documentés, au moins une fois par an.
• [engagement] Supervision de l'infrastructure avec alertes sur les anomalies de sécurité et de disponibilité.
• [en place] Limitation de débit sur les points d'accès publics. L'affirmation de la version 1.0 relative à un « anti-DDoS périmétrique via Cloudflare » est retirée : Cloudflare est utilisé pour le stockage objet et la diffusion des ressources statiques, et ne se trouve pas devant l'API.

D.4 Procédures de vérification

• [engagement] Test d'intrusion externe annuel.
• [engagement] Revue interne semestrielle des configurations de sécurité.
• [engagement] Gestion des vulnérabilités avec des objectifs de remédiation définis (critique : 7 jours ; élevée : 30 jours ; moyenne : 90 jours).

D.5 Continuité du traitement

• [engagement] Procédures documentées de reprise après sinistre et de gestion des incidents.
• [en place] Substituabilité des Sous-traitants ultérieurs d'infrastructure dans des délais raisonnables, le Service étant déployé à partir d'une définition de conteneur versionnée et non de services managés propres à un fournisseur.

D.6 Gestion des incidents

• [en place] Un point de contact unique nommément désigné pour la gestion des Violations de Données personnelles, joignable à privacy@tesserapp.eu.
• [engagement] Une procédure interne écrite de gestion des violations avec chaîne de notification prédéfinie, afin de garantir le respect du délai de 72 heures visé à l'art. 8 du présent DPA.

---

Contacts

• Sous-traitant : radioBros di Alberto Miconi, Via Ridolfino Venuti 30, 00162 Rome (Italie), numéro de TVA italien (Partita IVA) IT15127451001.
• E-mail pour toute question relative au présent DPA : privacy@tesserapp.eu.
• Autorité de contrôle compétente pour radioBros (établissement) : Autorité italienne de protection des données (Garante per la protezione dei dati personali) — gpdp.it. Les commerces établis dans un autre État membre de l'UE peuvent également contacter l'autorité de protection des données de leur propre pays pour les questions concernant le traitement des données de leurs clients.

---

Version 1.1 — adoptée le 8 septembre 2026, en remplacement de la version 1.0 du 30 mai 2026. Les versions historiques, lorsqu'elles sont disponibles, sont archivées au format PDF aux URL https://tesserapp.eu/legal/dpa/v{version}.pdf.