Politique de confidentialité

1. En bref

Tout ce qui figure dans la présente politique a été vérifié par rapport au code source de l'application. Si vous avez besoin d'un renseignement à ce sujet, veuillez utiliser les coordonnées indiquées à la section 2.

BrickDb est un service de ThreeB IT GmbH, sans annonces publicitaires. La présente politique décrit les données qui sont réellement traitées — et non ce que ce genre de texte dit habituellement.

• Votre consentement est demandé avant toute mesure d'audience avec Google Analytics. Sans lui, elle n'a pas lieu : aucun script n'est chargé, aucun identifiant n'est défini et rien n'est envoyé à Google. Les détails figurent à la section 10.
• Sans votre consentement, l'ouverture d'une page n'établit aucune connexion avec un tiers. Les polices de caractères, elles aussi, se trouvent sur notre propre serveur.
• Les photos sont visibles uniquement par vous et par les membres auxquels vous avez accordé, dans une collection partagée, l'accès aux informations privées ; elles n'apparaissent pas sur la page publique d'une collection. Les détails figurent à la section 8.2. Les métadonnées intégrées — y compris les coordonnées GPS — sont supprimées lors du traitement.
• Rien de ce qui permettrait de vous reconnaître n'est stocké sur l'appareil avant que vous ayez activement choisi un réglage, que vous vous soyez connecté ou que vous ayez donné votre consentement. Ce dont le navigateur a besoin, d'un point de vue purement technique, pour la sécurité des formulaires du site, et ce qui porte votre connexion, est énuméré intégralement à la section 6.1 ; ce que l'application dépose sur l'appareil figure à la section 6.5. Vous pouvez modifier à tout moment votre décision concernant la mesure d'audience, au bas de chaque page.

2. Responsable du traitement

Le responsable du traitement au sens de l'article 4, point 7), du RGPD est :

ThreeB IT GmbH
Bergstrang 105
49479 Ibbenbüren
Allemagne
Téléphone : +49 (5451) 893922-0
E-mail : hello@brickdb.net

Représentée par ses gérants (Geschäftsführer) Thimo Buchheister et Thorsten Brügge.

Aucun délégué à la protection des données n'a été désigné.

3. Consultation du site web

Lorsque www.brickdb.de ou l'une des autres adresses auxquelles BrickDb est accessible (www.brickdb.at, www.brickdb.ch, www.brickdb.dk, www.brickdb.nl, www.brickdb.be, www.brickdb.fr, www.brickdb.it, www.brickdb.lu, www.brickdb.es, www.brickdb.co.uk, www.brickdb.us, www.brickdb.com.mx, www.brickdb.eu, www.brickdb.net) est consultée, le serveur web traite les données qu'un navigateur doit transmettre pour des raisons techniques afin qu'une page puisse être délivrée : l'adresse IP, la date et l'heure de la requête, l'adresse demandée, le volume de données transféré et le code d'état, l'identifiant du navigateur et du système d'exploitation (user agent), ainsi que la préférence linguistique envoyée par le navigateur (Accept-Language).

Ces données sont nécessairement générées lors de toute connexion sur Internet. Elles sont traitées afin de délivrer la page, d'assurer le bon fonctionnement technique et de parer aux attaques.

La préférence linguistique fait l'objet d'une autre utilisation, étroitement limitée : l'indication de région qu'elle contient (par exemple DE dans de-DE) est lue pendant le traitement de la requête, afin de présélectionner un pays : sur la liste des événements, et pour les prix affichés sur les pages des sets et des minifigurines, c'est-à-dire les boutiques dont les prix sont affichés, la boutique Amazon vers laquelle le lien renvoie et la devise dans laquelle les prix sont affichés. Si vous êtes connecté et que vous avez enregistré un pays dans votre profil (section 7.2), c'est ce pays qui est utilisé à la place. Un pays que vous avez choisi et enregistré sur le site lui-même (section 6.1, bd-country) prévaut sur les deux. L'indication de région n'est pas stockée, n'est pas combinée à d'autres données et n'est pas transmise ; le pays choisi est visible sur la page — sur la liste des événements, également dans la barre d'adresse — et peut y être annulé en un clic.

Sur les adresses rattachées à un pays (par exemple www.brickdb.de ou www.brickdb.fr), le pays découle de l'adresse elle-même. Sur www.brickdb.net et www.brickdb.eu, qui ne sont rattachées à aucun pays en particulier, une indication supplémentaire est utilisée : le réseau de diffusion placé en amont du site (Azure Front Door, un service du sous-traitant Microsoft mentionné à la section 4) y déduit, en périphérie du réseau, un code de pays à deux lettres (par exemple SE) à partir de l'adresse IP de la requête et le transmet à l'application. Il sert la même finalité que l'indication de région : présélectionner un pays pour les prix et les événements. L'application ne reçoit rien d'autre que ce code, et en particulier aucune localisation plus précise ; le code n'est ni stocké, ni journalisé, ni combiné à d'autres données. Aucun service de géolocalisation d'un tiers n'est utilisé ; l'adresse IP n'est divulguée à cette fin à personne qui ne la traite pas déjà de toute façon pour délivrer la page. La base juridique en est l'article 6, paragraphe 1, point f), du RGPD ; l'intérêt légitime consiste à vous montrer les prix et les événements de votre propre pays sans vous le demander au préalable. Vous pouvez à tout moment passer outre en choisissant vous-même un pays sur le site (section 6.1, bd-country).

Base juridique : article 6, paragraphe 1, point f), du RGPD. L'intérêt légitime réside dans l'exploitation techniquement irréprochable et sûre du service.

Durée de conservation : l'application elle-même ne tient aucun journal des accès. Les journaux générés au niveau de l'infrastructure ne sont conservés que pendant la durée nécessaire à la sécurité de l'exploitation, et pendant 30 jours au plus, à moins qu'ils ne soient nécessaires pour élucider un incident de sécurité précis.

4. Hébergement

Le service est exploité sur Microsoft Azure ; le fournisseur est Microsoft Ireland Operations Limited, One Microsoft Place, South County Business Park, Leopardstown, Dublin 18, Irlande. La région Azure Germany West Central (Frankfurt am Main) a été choisie comme lieu de traitement ; la base de données et le stockage de fichiers se trouvent donc en Allemagne.

À cet égard, Microsoft est sous-traitant au sens de l'article 28 du RGPD, sur la base du Microsoft Products and Services Data Protection Addendum.

Les requêtes adressées à BrickDb passent par le réseau de diffusion Azure Front Door de Microsoft. Il reçoit la connexion à un emplacement proche de vous — qui peut se trouver hors d'Allemagne et hors de l'UE et de l'EEE — et la transmet ; l'application et toutes les données stockées restent dans Germany West Central (Frankfurt am Main). Cela aussi a lieu dans le cadre de la sous-traitance, sur la base du Microsoft Products and Services Data Protection Addendum ; dans la mesure où cela implique un transfert vers un pays tiers, s'y applique ce que le paragraphe suivant dit de Microsoft sous « Transfert vers des pays tiers ».

Transfert vers des pays tiers : un accès depuis des pays tiers ne peut être totalement exclu dans le cadre d'opérations d'assistance et de maintenance. Microsoft fonde de tels transferts sur les clauses contractuelles types de la Commission européenne et est en outre certifiée au titre de l'EU-US Data Privacy Framework.

5. Polices de caractères et contenus externes

Les polices de caractères utilisées sont délivrées depuis notre propre serveur. Aucune police n'est chargée depuis des serveurs de tiers — en particulier pas depuis Google Fonts. Il n'y a ni cartes, ni vidéos, ni modules de réseaux sociaux, ni autres contenus de tiers intégrés.

Sans votre consentement, l'ouverture d'une page n'établit aucune connexion avec un tiers et ne transmet aucune adresse IP à un tiers.

La seule exception est la mesure d'audience décrite à la section 10, et elle n'est pas une restriction de cette phrase mais sa condition : le script de Google n'est chargé qu'après que vous avez accepté dans le bandeau de consentement. Tant que vous n'avez ni accepté ni refusé, rien de Google n'est chargé — pas même un signal préalable dit « sans cookie ».

6. Stockage sur l'appareil

BrickDb ne dépose aucun cookie à des fins de marketing ou de publicité. Seuls sont stockés ce qui consigne un réglage délibérément choisi, ce qu'exige la sécurité des formulaires, ce qui porte votre connexion si vous vous connectez — et, si vous avez accepté la mesure d'audience décrite à la section 10, les cookies d'analyse qui y sont décrits. Aucun des cookies d'analyse n'est déposé avant votre accord.

6.1 Ce qui est stocké

Les cinq premières entrées ne contiennent rien d'autre que la dernière valeur sélectionnée. Elles ne contiennent aucun identifiant et rien qui permettrait de reconnaître une personne ou un appareil. Toutes les cinq relèvent d'un stockage propre au site ; aucun tiers n'y a accès. Chacune ne vaut que pour l'adresse sur laquelle elle a été déposée : un choix fait sur www.brickdb.de n'est pas lu sur www.brickdb.fr. bd-country apparaît lorsque vous choisissez et enregistrez un pays, bd-market-hint lorsque vous fermez l'avis indiquant qu'il existe une adresse propre à votre pays — il a pour seul effet que cet avis ne vous soit pas affiché de nouveau à chaque page. bd-analytics-consent est en outre défini comme HttpOnly, car aucun script du navigateur n'a besoin de le lire : c'est le serveur qui décide si la mesure d'audience fonctionne, avant que la page n'existe.

La sixième entrée est déposée par le framework web utilisé sur chaque page contenant un formulaire — y compris la page sur laquelle se trouve le bandeau de consentement. Elle protège ces formulaires contre un envoi depuis un site étranger (cross-site request forgery), ne contient aucune information vous concernant, est HttpOnly et SameSite=Strict, et prend fin avec la session. Pour le bandeau de consentement, elle est la raison pour laquelle personne ne peut, de l'extérieur, déclencher un accord en votre nom.

Les deux entrées suivantes n'apparaissent que lorsque vous vous connectez. bd.auth contient votre session de connexion ; son contenu est chiffré, il est HttpOnly et Secure, et il n'est envoyé qu'à ce site (SameSite=Lax). Il ne se prolonge pas de lui-même : la session prend fin avec la validité de la connexion, et non lorsque vous cessez de cliquer ; la déconnexion le supprime. Les deux cookies d'échange (handshake) ne sont déposés par le framework que pour la durée d'une seule connexion ; ils lient le retour depuis l'écran de connexion à la tentative que vous avez effectivement lancée, et sont supprimés ensuite.

La dernière entrée correspond aux cookies d'analyse de la section 10. Ils sont déposés uniquement après votre consentement et contiennent un identifiant aléatoire permettant de reconnaître les visites répétées depuis le même navigateur.

6.2 Pourquoi aucun consentement n'est requis pour les entrées autres que les cookies d'analyse

La disposition applicable est l'article 25 de la loi allemande sur la protection des données dans les télécommunications et les services numériques (TDDDG). Il vise tout stockage d'informations sur un équipement terminal et tout accès à celles-ci — donc non seulement les cookies, mais expressément aussi le stockage local. En vertu de l'article 25, paragraphe 2, point 2, de la TDDDG, le consentement n'est pas requis lorsque le stockage est strictement nécessaire à la fourniture d'un service expressément demandé par l'utilisateur.

Tel est le cas ici, et ce pour des raisons qui peuvent être vérifiées dans le comportement de l'application :

• Rien n'est stocké avant un choix actif. La simple ouverture de la page n'écrit aucune entrée. Une entrée n'apparaît que lorsque les sélecteurs de thème ou de langue sont actionnés, lorsque vous choisissez et enregistrez un pays, ou lorsque vous fermez l'avis signalant l'adresse d'un autre pays.
• Le retour au réglage par défaut supprime de nouveau l'entrée. Si "Système" est sélectionné, l'entrée correspondante est supprimée au lieu d'être écrasée.
• Ce qui est stocké est exactement le réglage qui a été expressément demandé, et rien d'autre.
• Il en va de même pour bd-analytics-consent, pour une raison qui lui est propre : il consigne la décision que vous venez de prendre. Sans lui, la question devrait être posée de nouveau sur chaque page — y compris à quelqu'un qui vient tout juste de refuser.
• Le cookie anti-falsification (antiforgery) est le cas le plus clair des trois : sans lui, un formulaire de ce site ne peut plus être protégé contre un usage abusif venu de l'extérieur, et cela concerne aussi le bouton par lequel vous acceptez ou refusez la mesure d'audience. Il n'est pas stocké parce que quelque chose doit être mesuré, mais pour que la saisie qui compte soit la vôtre.
• Pour les trois cookies de connexion, c'est on ne peut plus net : sans eux, une connexion ne peut être ni effectuée ni maintenue. Quiconque se connecte demande précisément le service qu'ils rendent, et ils n'apparaissent qu'au moment où il est demandé — quiconque ne se connecte pas n'en reçoit aucun.

Un réglage mémorisé sur demande expresse est donc strictement nécessaire à la fourniture du service demandé ; pour la sécurité des formulaires et pour la connexion, cela vaut de toute façon. Aucun consentement n'est donc recueilli pour ces entrées.

Opposition et suppression : les entrées relatives au thème et à la langue peuvent être supprimées à tout moment en sélectionnant de nouveau "Système" dans le sélecteur ou en effaçant les données du navigateur. Le site fonctionne sans elles de manière inchangée ; il s'affiche alors avec le thème et dans la langue que prescrivent respectivement le système d'exploitation ou le navigateur. Vous supprimez les entrées relatives au pays et à l'avis fermé en effaçant les données du navigateur ; sans elles, le pays est de nouveau présélectionné comme le décrit la section 3.

6.3 Cookies d'analyse — uniquement après consentement

L'article 25, paragraphe 2, point 2, de la TDDDG ne s'applique pas aux cookies de la mesure d'audience : une mesure d'audience n'est pas nécessaire au service que vous avez demandé, et le site fonctionne entièrement sans elle. Ils relèvent donc de l'article 25, paragraphe 1, de la TDDDG et ne sont déposés qu'après que vous avez accepté dans le bandeau de consentement. Le bandeau apparaît sur la première page que vous ouvrez et propose l'acceptation et le refus sous la forme de deux boutons de même taille, côte à côte — l'un comme l'autre en un seul clic.

6.4 Données de connexion techniquement nécessaires

L'interface utilisateur est rendue côté serveur et maintient une connexion WebSocket avec le serveur pendant son utilisation. L'état de session correspondant réside exclusivement dans la mémoire vive du serveur, n'est pas stocké sur l'équipement terminal et prend fin à la fermeture de la page.

6.5 Dans l'application

L'application BrickDb pour appareils mobiles et ordinateurs affiche les mêmes pages, mais ne dépose rien dans un stockage de navigateur. Les réglages de thème et de langue s'y trouvent dans le magasin de réglages du système d'exploitation et ne contiennent, comme à la section 6.1, rien d'autre que la dernière valeur sélectionnée.

Si vous vous connectez dans l'application, votre session est déposée dans le stockage protégé de l'appareil — le trousseau (Keychain) sous iOS et macOS, le stockage sécurisé par Keystore sous Android. Quatre éléments y sont déposés : le jeton d'accès, le jeton d'actualisation, le moment d'expiration et l'indication de la voie par laquelle vous vous êtes connecté.

S'y ajoute le jeton d'identité, et c'est le seul de ces éléments qui contienne des informations vous concernant. Il est émis par Auth0 lors de la connexion et y est conservé parce que l'application y lit à qui elle a affaire. Il contient l'identifiant de votre compte auprès du fournisseur d'identité, votre nom et votre adresse e-mail, l'indication de la confirmation ou non de cette adresse, ainsi qu'une valeur technique à usage unique issue de la connexion. Ces informations se trouvent donc sur l'appareil, même si, conformément à la section 7.1, elles ne sont pas reprises dans notre base de données. Aucun mot de passe n'en fait partie, car l'application n'en accepte jamais (section 7.1).

Les cinq éléments sont supprimés lors de la déconnexion. Aucune copie de votre collection n'est conservée sur l'appareil, et aucune modification n'est mise en attente en vue d'une transmission ultérieure.

7. Compte utilisateur

7.1 Connexion

BrickDb peut être utilisé sans compte : le catalogue, la recherche et le scanner sont accessibles sans connexion. Vous n'avez besoin d'un compte que pour tenir votre propre collection.

La connexion passe par le fournisseur d'identité Auth0 (Okta, Inc.), au moyen d'un tenant situé dans l'Union européenne. Trois voies sont proposées : un compte avec une adresse e-mail et un mot de passe, la connexion avec un compte Google existant, ou la connexion avec votre compte Apple ("Se connecter avec Apple"). Vous choisissez celle que vous utilisez. Cela vaut de la même manière pour le site web et pour l'application.

Le formulaire de connexion est une page d'Auth0, et non de BrickDb. Un mot de passe n'est jamais saisi sur une page de BrickDb, ni reçu ni transmis par elle ; la modification d'un mot de passe a également lieu chez Auth0. Quiconque se connecte avec Google ou Apple n'a aucun mot de passe chez Auth0 — les données d'accès se trouvent alors chez Google ou chez Apple, et BrickDb ne les voit pas davantage. Avec "Se connecter avec Apple", vous pouvez en outre choisir de masquer votre adresse e-mail : BrickDb reçoit alors une adresse du service de relais d'Apple (se terminant par @privaterelay.appleid.com), par laquelle Apple vous transfère nos e-mails.

Ce que BrickDb reçoit. Après une connexion réussie, Auth0 remet les informations qui ont été demandées : un identifiant pseudonyme de votre compte, les informations de profil enregistrées avec la connexion, et votre adresse e-mail. Rien de tout cela n'est stocké, hormis l'identifiant pseudonyme et le moment de la création de l'enregistrement — c'est là tout le contenu de notre propre enregistrement de compte. Votre nom, votre profil et votre adresse e-mail restent chez Auth0 et y sont lus lorsqu'ils sont nécessaires (section 7.2) ; ils ne sont pas repris dans notre base de données.

L'authentification à deux facteurs est proposée et jamais exigée. Quiconque le souhaite peut enregistrer une application d'authentification (TOTP), une clé liée à l'appareil telle que Face ID, Touch ID ou Windows Hello, une clé de sécurité matérielle et des codes de récupération. Sans un tel enregistrement, personne ne se voit demander un second facteur. Les codes par SMS ou par e-mail ne sont délibérément pas proposés.

Ce qu'Auth0 traite à cette occasion. Auth0 traite les données de connexion elles-mêmes ainsi que les données techniques de chaque opération de connexion — moment, adresse IP, identifiant du navigateur et de l'appareil — afin d'effectuer la connexion et de détecter les tentatives de connexion abusives. Lors de la création d'un compte et à chaque modification de mot de passe, Auth0 vérifie en outre si le mot de passe choisi est apparu dans une violation de données connue, et le refuse dans ce cas. Cette vérification n'a pas lieu lors d'une connexion ordinaire.

Base juridique : article 6, paragraphe 1, point b), du RGPD — sans compte, les fonctions de collection ne peuvent pas être fournies. Pour la détection des tentatives de connexion abusives et la vérification par rapport aux mots de passe connus pour avoir été compromis, article 6, paragraphe 1, point f), du RGPD ; l'intérêt légitime réside dans la sécurité des comptes. Auth0 est à cet égard sous-traitant au sens de l'article 28 du RGPD.

Transfert vers un pays tiers : le tenant se trouve dans l'Union européenne, et c'est là que la connexion a lieu. Le cocontractant est toutefois Okta, Inc. (Auth0), dont le siège est aux États-Unis, de sorte qu'un accès depuis ce pays — par exemple dans le cadre de l'assistance et de la maintenance — ne peut être exclu. Okta fonde de tels transferts sur les clauses contractuelles types de la Commission européenne, jointes en tant que documents distincts à son accord de sous-traitance du 15 décembre 2023.

Durée de conservation : l'enregistrement de compte existe jusqu'à ce que vous supprimiez votre compte. La suppression sur la page du compte supprime également le compte chez Auth0 et, avec lui, les informations qui y sont enregistrées (section 14).

7.2 Profil : nom, texte de présentation, pays et adresse facultative

Vous pouvez enregistrer un prénom, un nom, un court texte à propos de vous, votre pays, l'un de nos dessins d'avatar et — de manière facultative — une adresse postale complète.

Rien de tout cela n'est stocké par BrickDb. Ces informations se trouvent chez le fournisseur d'identité Auth0, avec votre compte de connexion ; BrickDb les y lit et les y écrit au lieu d'en conserver une copie : notre propre enregistrement de compte ne contient rien d'autre qu'un identifiant pseudonyme et le moment de sa création. Si vous supprimez votre compte conformément à la section 14, le compte Auth0 est supprimé, et ce profil avec lui.

Chaque champ est facultatif. Rien de tout cela n'est requis, rien n'est une condition de l'utilisation de BrickDb, et aucune fonction ne vous est refusée parce que vous laissez un champ vide. Vous pouvez modifier ou effacer chaque information à tout moment.

Pourquoi l'adresse, en particulier, est demandée. Deux finalités, toutes deux indiquées ici avant que le champ ne soit proposé, et non après coup :

• Estimation à des fins d'assurance. BrickDb proposera une estimation d'une collection à des fins d'assurance. Une telle estimation est liée au lieu où la collection est conservée ; un assureur ne l'accepte pas sans cette indication.
• Une place de marché prévue, avec BrickDb comme tiers de confiance. BrickDb a l'intention de proposer une place de marché sur laquelle BrickDb intervient comme tiers de confiance entre l'acheteur et le vendeur. L'adresse postale d'une partie est ce qui rend une telle opération imputable et un litige susceptible d'être réglé.

Aucun de ces deux services n'existe encore. L'adresse n'est utilisée pour rien d'autre : ni pour la publicité, ni pour le profilage, ni pour une quelconque forme de scoring, et elle n'est pas transmise à des tiers.

Votre pays est en outre utilisé pour présélectionner un pays sur la liste des événements et pour les prix affichés sur les pages des sets et des minifigurines, avant la préférence linguistique du navigateur décrite à la section 3. Il est lu à cette fin chez Auth0 lors de l'affichage d'une telle page, n'est pas stocké par BrickDb à cette fin et n'est pas transmis, et le choix peut être annulé sur la page en un clic.

Le pays et la langue que vous choisissez sur le site. Si vous choisissez et enregistrez, en étant connecté, un pays et une langue pour le site, les deux sont enregistrés auprès de votre compte de connexion chez Auth0, en plus des entrées dans le navigateur (section 6.1), afin que le choix vaille aussi sur un autre appareil et à une autre adresse de BrickDb. BrickDb n'en conserve pas non plus de copie propre. Si vous n'êtes pas connecté, le choix reste dans le seul navigateur.

Base juridique : pour le prénom, le nom, le texte de présentation, le pays et la langue choisie, article 6, paragraphe 1, point b), du RGPD — le traitement fait partie du service demandé. Pour l'adresse, article 6, paragraphe 1, point a), du RGPD — consentement, donné en remplissant le champ et révocable à tout moment en l'effaçant. Le retrait du consentement n'affecte en rien votre compte par ailleurs et ne porte pas atteinte à la licéité du traitement effectué jusque-là.

Le profil est inclus dans la copie de vos données prévue à la section 14 et est supprimé avec votre compte conformément à la même section.

7.3 Envoi d'e-mails

BrickDb n'envoie des e-mails que lorsqu'il existe pour cela une occasion précise : la confirmation de votre adresse e-mail et la réinitialisation de votre mot de passe, une invitation à une collection lorsque quelqu'un vous y invite (section 8.1a), une invitation à choisir votre mot de passe lorsque l'administration crée un compte pour vous (section 8.9), notre réponse à une demande d'assistance, ainsi qu'une notification à notre propre boîte aux lettres lorsque quelqu'un en dépose une — cette dernière nous est adressée, et non à vous, mais elle contient ce que le demandeur a écrit (la section 8.7 traite des deux) —, une notification à notre propre boîte aux lettres lorsque quelqu'un signale un contenu, et l'exposé des motifs qui vous est adressé lorsqu'il est fait droit à un signalement portant sur un contenu que vous avez publié (les deux à la section 8.8). Il n'y a ni newsletter ni e-mail publicitaire.

Le prestataire d'envoi est Twilio Inc. (“SendGrid”), 101 Spear Street, 5th Floor, San Francisco, CA 94105, USA. SendGrid reçoit à cette fin l'adresse du destinataire, un nom d'affichage s'il en existe un, l'objet et le contenu intégral du message, ainsi que les données techniques de remise (moment, statut de remise, réponse du serveur de messagerie destinataire). Votre adresse e-mail est donc transmise à un tiers, et ce en tout premier lieu — avant qu'il ne lui arrive quoi que ce soit d'autre. C'est pourquoi cela est indiqué ici, et non plus bas à la section 12.

Base juridique : article 6, paragraphe 1, point b), du RGPD — la confirmation d'une adresse, la réinitialisation d'un mot de passe et la remise d'une invitation font partie du service demandé. SendGrid est à cet égard sous-traitant au sens de l'article 28 du RGPD, sur la base du Twilio Data Protection Addendum.

Transfert vers un pays tiers : l'envoi passe par l'infrastructure mondiale de SendGrid ; le traitement a donc lieu aux États-Unis — et non en Allemagne, comme l'hébergement décrit à la section 4. Twilio fonde de tels transferts sur les clauses contractuelles types de la Commission européenne et est en outre certifiée au titre de l'EU-US Data Privacy Framework.

Mesure des ouvertures et des clics : oui pour les e-mails relatifs au compte, non pour les nôtres. Les e-mails concernant votre compte — confirmation de l'adresse, réinitialisation du mot de passe — sont complétés par SendGrid, avant l'envoi, par une image invisible, et leurs liens sont redirigés via SendGrid. Lorsque votre logiciel de messagerie affiche un tel message, il charge cette image et transmet ce faisant le moment et votre adresse IP à SendGrid ; il en va de même lorsque vous cliquez sur un lien. SendGrid en tire l'information de savoir si et quand un tel message a été ouvert. Base juridique : article 6, paragraphe 1, point f), du RGPD — notre intérêt légitime à ce que les e-mails relatifs au compte arrivent et ne finissent pas dans un dossier de courrier indésirable. Vous pouvez vous y opposer en vertu de l'article 21 du RGPD en utilisant les coordonnées indiquées à la section 2, et vous pouvez désactiver le chargement des images dans votre logiciel de messagerie, auquel cas aucune mesure des ouvertures n'a lieu.

Les e-mails que BrickDb envoie lui-même ne contiennent ni une telle image ni des liens redirigés — il s'agit aujourd'hui des invitations à une collection, des deux e-mails d'assistance de la section 8.7, à savoir notre réponse à une demande et la notification qu'elle nous envoie, ainsi que des deux e-mails relatifs aux signalements de la section 8.8. Aucun d'eux ne demande quoi que ce soit à un serveur lors de son ouverture ; chaque envoi désactive expressément les deux mesures chez SendGrid.

Durée de conservation : BrickDb ne conserve aucune copie d'un message envoyé. Chez le prestataire d'envoi, les données de remise restent consultables dans son journal d'activité pendant une courte période qui dépend de son offre tarifaire.

État de la présente version : cette section décrit la voie d'envoi telle qu'elle existe actuellement. Jusqu'à ce que s'y ajoute la notification relative à une demande d'assistance mentionnée ci-dessus, on lisait ici “telle qu'elle existe depuis le 10 septembre 2026”.

8. Données de collection et photos

Les indications qui suivent décrivent le traitement qui a lieu avec un compte au sens de la section 7.

8.1 Données de collection

Est stocké ce que vous saisissez vous-même : numéro de set, désignation, indications sur l'état, notes, date d'acquisition, prix payé, informations sur le vendeur, ainsi que les moments de la création et de la dernière modification. Ces indications sont liées à un identifiant pseudonyme.

Est stocké de la même manière ce que vous saisissez dans les autres rubriques : les minifigurines individuelles et pièces détachées avec les mêmes indications, les exemplaires de numéros de magazines et de livres avec leur note d'état, l'état d'un polybag joint, vos remarques sur leur état, la manière et le moment de leur acquisition, le prix payé, l'information sur le vendeur et vos notes, les collections avec leur nom, leur description, leur visibilité au sens de la section 8.1a et leurs membres ainsi que le rôle de chacun, les invitations que vous avez émises ainsi que l'adresse e-mail indiquée à cette fin, les signatures que vous enregistrez pour un exemplaire, votre liste de souhaits, vos contributions à la résolution des codes de sachet et des codes-barres de boîte, et les lots de photos de boîtes que vous soumettez au traitement.

Les exemplaires de numéros de magazines et de livres ne sont rangés dans aucune collection ; vous seul les voyez.

Emplacements de rangement. Vous pouvez consigner l'endroit où vos objets sont conservés : des salles, des endroits dans une salle et des compartiments dans un endroit, chacun avec le nom que vous lui donnez, son niveau et sa position dans votre liste, et pour chaque exemplaire — sets, minifigurines, pièces détachées, numéros de magazines et livres — l'emplacement où il se trouve. Vos emplacements de rangement vous appartiennent, et non à une collection : vous seul pouvez les créer, les modifier ou les attribuer. L'emplacement d'un exemplaire dans une collection partagée est visible, en lecture seule, par les membres dont le rôle dans cette collection est Propriétaire ou Éditeur ; les membres ayant le rôle Lecteur ou Assurance ne le voient jamais, et une collection publiée ne le montre jamais (section 8.1a). Si vous supprimez votre compte (section 14), vos emplacements de rangement sont supprimés, et l'emplacement est d'abord retiré de chaque exemplaire qui en mentionnait un — y compris d'un exemplaire qui reste dans une collection partagée avec d'autres personnes.

Les champs de texte libre ne sont pas exploités. Vous êtes prié de ne pas y saisir de catégories particulières de données à caractère personnel au sens de l'article 9 du RGPD.

Base juridique : article 6, paragraphe 1, point b), du RGPD — le traitement est nécessaire à la fourniture du service demandé.

8.1a Qui peut voir une collection

Chaque exemplaire qui vous appartient est rangé dans une collection, et une collection a l'un de trois réglages, que vous choisissez et pouvez modifier à tout moment : privée (seuls ses membres la voient — le réglage par défaut d'une nouvelle collection), toute personne avec le lien, ou tout le monde, moteurs de recherche compris.

Une collection que vous avez rendue publique montre son nom et sa description, les numéros de set, les noms des sets, le nombre d'exemplaires que vous détenez de chacun et l'état dans lequel ils se trouvent, et rien d'autre. Ni photos, ni notes, ni étiquettes, ni surnoms, ni lieux de rangement, ni prix payés, ni estimations de valeur, ni dates d'acquisition, et rien sur le vendeur. Elle ne nomme ni vous ni aucun autre membre, et elle n'indique pas non plus combien de personnes en font partie. Ces champs ne sont pas masqués sur cette page — ils ne lui sont tout simplement pas transmis.

Un lien n'est pas un mot de passe. Une collection réglée sur “toute personne avec le lien” est délivrée à quiconque demande cette adresse, que vous la lui ayez donnée ou non. Le réglage “toute personne avec le lien” demande en outre aux moteurs de recherche de ne pas répertorier la page, ce qu'ils respectent en règle générale sans y être tenus. Remettre une collection en mode privé met fin immédiatement à sa délivrance, mais ne permet pas de récupérer une copie que quelqu'un — ou un moteur de recherche — a déjà prise.

Une collection partagée avec des membres nommément désignés est autre chose qu'une collection publique : ce que voit chaque membre dépend du rôle que vous lui avez attribué. Un Lecteur voit exactement ce que montre la page publique. Un Éditeur voit tout, y compris les champs énumérés ci-dessus. Le rôle Assurance voit les sets, leur état et les chiffres d'estimation, et rien du reste.

Une collection publique peut être signalée. Sa page comporte le formulaire de signalement décrit à la section 8.8, utilisable par toute personne qui peut voir la page. Si l'administration fait droit à un signalement la concernant, la collection est remise en mode privé ; rien n'y est supprimé et vous pouvez la publier de nouveau.

Base juridique : article 6, paragraphe 1, point a), du RGPD — vous consentez en choisissant le réglage, et vous retirez votre consentement en le rétablissant.

8.2 Photos

Les photos téléversées sont affichées à vous-même et aux membres de la collection dont le rôle inclut les informations privées — à savoir Propriétaire et Éditeur au sens de la section 8.1a. Si l'exemplaire se trouve dans une collection dont personne d'autre ne fait partie, seule la personne qui a téléversé la photo la voit. Les photos n'apparaissent pas sur la page publique d'une collection, et les membres ayant le rôle Lecteur ou Assurance ne les voient pas non plus. Les photos ne sont pas publiées, ne sont pas transmises à des tiers et ne sont pas utilisées pour entraîner des modèles.

Les métadonnées sont supprimées. Lors du téléversement, chaque image est réencodée : l'orientation consignée dans l'image est intégrée de manière définitive aux données d'image, puis l'ensemble du profil de métadonnées est supprimé — EXIF, IPTC et XMP, et donc en particulier les coordonnées GPS, le moment de la prise de vue et les identifiants de l'appareil. Seule l'image nettoyée est stockée ; le fichier transmis à l'origine n'est pas conservé.

Le nom de fichier d'origine n'est pas repris. Chaque fichier reçoit un identifiant généré de manière aléatoire ; le chemin de stockage ne permet de rien déduire sur la personne qui a téléversé le fichier ni sur son origine.

Versions réduites. Pour l'affichage, des versions réduites d'une photo sont générées à la demande et mises en cache. Elles contiennent les mêmes données d'image — déjà débarrassées des métadonnées —, sont soumises aux mêmes restrictions d'accès et sont supprimées en même temps que la photo.

Les images dans un format qui ne peut pas être réencodé — dont HEIC/HEIF, le format standard des iPhone récents — sont refusées au lieu d'être stockées. Le message d'erreur indique les formats acceptés (JPEG, PNG, WebP, GIF). Rien n'est donc déposé dans le stockage qui n'ait été nettoyé au préalable.

Pour chaque photo sont stockés : l'identifiant de fichier aléatoire, une légende que vous attribuez vous-même, l'ordre de tri et le moment du téléversement.

Base juridique : article 6, paragraphe 1, point b), du RGPD.

8.3 Image d'avatar

Vous pouvez téléverser votre propre image comme avatar, ou utiliser l'un des dessins fournis par BrickDb. Les dessins fournis sont nos propres créations graphiques et ne sont pas des données à caractère personnel ; une image téléversée en est une.

Un avatar téléversé passe par le même nettoyage que toute autre photo : l'orientation est intégrée aux données d'image et l'ensemble du profil de métadonnées — EXIF, IPTC et XMP, et donc en particulier les coordonnées GPS, le moment de la prise de vue et les identifiants de l'appareil — est supprimé. L'image est ensuite recadrée sur son carré central, réduite à 256 × 256 pixels et réencodée en WebP. Seule cette image est stockée ; le fichier transmis n'est pas conservé, et une image qui ne peut pas être réencodée est refusée au lieu d'être stockée.

Qui peut le voir. Un avatar est stocké afin de pouvoir être affiché à côté de votre nom. BrickDb ne dispose actuellement d'aucun écran sur lequel une personne voit le profil d'une autre ; aujourd'hui, vous seul voyez donc le vôtre. Dès que cela changera, la présente section le dira expressément : un avatar est destiné à être visible par d'autres utilisateurs, et c'est précisément pourquoi il est décrit ici séparément de la section 8.2.

Un seul avatar est stocké par compte ; un nouveau téléversement le remplace. Il est inclus dans la copie de vos données prévue à la section 14 et il est supprimé lorsque vous supprimez votre compte conformément à la section 14.

Base juridique : article 6, paragraphe 1, point b), du RGPD.

8.4 Propositions d'événements

Lorsque vous soumettez un événement, nous stockons son titre, sa description facultative, son lieu, son pays et son calendrier. Pour un événement d'une journée entière, il s'agit de la date de début et de la date de fin non incluse. Pour un événement avec horaire, il s'agit des moments de début et de fin ainsi que du fuseau horaire du lieu de l'événement. S'y ajoutent l'ouverture facultative des inscriptions, l'URL source, le lien avec votre compte et le moment de la soumission. Nous stockons en outre le statut de modération, le moment d'une décision de modération et un ordre de notification interne destiné à la file d'attente d'examen. Cet ordre n'envoie aucun e-mail.

L'administration examine les propositions manuellement. Les propositions en attente et refusées ne sont pas publiques. Après approbation, les informations sur l'événement et l'URL source sont publiquement visibles ; l'identité de votre compte n'est pas publiée. Veuillez ne soumettre que des informations sur l'événement que vous êtes autorisé à publier, sans coordonnées personnelles ni informations privées sur vous-même ou sur d'autres personnes.

La soumission et la modération fournissent le service demandé (article 6, paragraphe 1, point b), du RGPD). Le maintien du calendrier public approuvé sert notre intérêt légitime et celui des autres visiteurs à disposer d'informations fiables sur les événements (article 6, paragraphe 1, point f), du RGPD). Vous pouvez vous opposer à un traitement fondé sur des intérêts légitimes en utilisant les coordonnées indiquées à la section 2. L'export de données au titre de l'article 15 du RGPD, sur la page du compte, contient vos propositions d'événements dans chaque statut de modération.

Lors de la suppression du compte, les propositions en attente et refusées sont supprimées avec leurs ordres de notification. Les événements approuvés restent publics ; le lien avec la personne qui les a soumis est anonymisé : une nouvelle valeur aléatoire le remplace, sans compte ni correspondance permettant de remonter jusqu'à vous. Les informations approuvées restent dans le calendrier pour les autres visiteurs ; il n'existe pas de délai d'expiration fixe pour cet enregistrement anonymisé. Pour les copies de sauvegarde, la section 13 s'applique. Les autres droits prévus à la section 14 demeurent.

8.5 Lecture du numéro de set à partir d'une photo

Lorsque vous soumettez expressément une photo d'une boîte de vente pour la lecture du numéro de set, BrickDb transmet au plus 8 Mo du navigateur à ses propres serveurs web et API. Le serveur API transmet la photo, inchangée, à un troisième serveur qui nous est propre, le service de lecture (l'application conteneur “brickdb-ocr”). Il fonctionne dans le même environnement Azure et dans la même région (Germany West Central, Frankfurt am Main) que les autres serveurs décrits à la section 4, n'est accessible que depuis l'intérieur de cet environnement et n'a aucun accès à la base de données ni au stockage de fichiers. Comme les serveurs web et API, le service de lecture ne détient l'image qu'en mémoire vive ; il ne renvoie au serveur API que les numéros de set possibles qui y ont été lus, et son entrée de journal consigne uniquement l'issue de la requête (par exemple lue ou rejetée) et sa durée, rien sur la photo. Sur aucun des trois serveurs l'image n'est stockée, journalisée ou utilisée pour entraîner des modèles ; elle n'est pas transmise à des tiers et est écartée à la fin de la requête. Nous exploitons nous-mêmes les trois serveurs sur Microsoft Azure ; Microsoft agit à cet égard en tant que sous-traitant, comme décrit à la section 4. Base juridique : article 6, paragraphe 1, point b), du RGPD — ce traitement fournit la lecture que vous avez demandée.

Afin que cette fonction gourmande en calcul reste disponible, chaque processus serveur autorise six requêtes par adresse IP d'origine au cours d'une minute glissante. Cette limite est vérifiée à la fois par le serveur web et par le serveur API, parce que le serveur API est également accessible directement. Chaque processus serveur compte pour lui-même, et plusieurs processus de chaque serveur peuvent fonctionner en même temps ; la limite vaut donc par processus, et non comme un total pour l'ensemble de BrickDb. Afin que le serveur API compte votre adresse, et non celle du serveur web, lorsqu'une requête passe par le serveur web, ce dernier lui transmet votre adresse avec la requête ; le service de lecture ne la reçoit pas. Sur les deux serveurs, l'adresse — pour IPv6, uniquement sa partie réseau — n'est détenue que comme clé dans la mémoire vive du processus serveur concerné ; elle n'est ni journalisée, ni stockée durablement, ni communiquée à des tiers. Après une minute, elle n'influence plus aucune décision et est supprimée lorsque cette adresse revient ou que le nettoyage déclenché par les requêtes a besoin de place. Chaque processus serveur détient au plus 1 024 clés d'adresse ; tant que toutes les places sont encore actives, une nouvelle adresse est rejetée au lieu d'en évincer une. Base juridique : article 6, paragraphe 1, point f), du RGPD. L'intérêt légitime est la disponibilité techniquement sûre, fiable et équitable du service.

8.6 Suggestion sur l'état d'une boîte à partir d'une photo

Indépendamment de la lecture du numéro de set, vous pouvez demander expressément, pour une photo d'une boîte de vente, une suggestion sur l'état visible de la boîte. Ce n'est que lorsque vous avez demandé cette évaluation et confirmé la demande que BrickDb transmet la photo depuis son propre serveur API au service Azure OpenAI de Microsoft Ireland Operations Limited, One Microsoft Place, South County Business Park, Leopardstown, Dublin 18, Irlande, en tant que sous-traitant au sens de l'article 28 du RGPD. Auparavant, l'image est réencodée, débarrassée de toutes ses métadonnées et réduite à 1 024 pixels au plus sur son plus grand côté. La connexion est établie par le serveur, et non par votre navigateur ; l'ouverture d'une page ne la déclenche jamais.

Le traitement a lieu dans la zone de données UE (EU Data Zone) d'Azure, c'est-à-dire au sein de l'UE ; le déploiement est placé dans la région Germany West Central et le traitement peut avoir lieu dans tout État membre de l'UE. Selon Microsoft, les entrées et les sorties ne sont pas utilisées pour entraîner les modèles et ne sont pas mises à la disposition des fournisseurs des modèles. Surveillance des abus par défaut : Microsoft contrôle automatiquement les entrées pour détecter une utilisation abusive. Une entrée signalée par ce contrôle peut être conservée par Microsoft à titre d'échantillon et examinée par des employés autorisés de Microsoft dans l'EEE ; Microsoft n'indique pour cela aucune durée maximale fixe de conservation. Au-delà, le service ne conserve pas la photo.

BrickDb lui-même reste sans état : BrickDb ne stocke pas la photo ni le résultat, ne les journalise pas, et ni l'un ni l'autre ne sont utilisés pour entraîner des modèles ; les deux sont écartés à la fin de la requête. Le résultat est une suggestion expérimentale et non calibrée portant uniquement sur l'état visible de la boîte — il n'existe aucun taux de réussite mesuré, elle ne dit rien du contenu, du scellé ni de l'intégralité, elle n'inscrit rien dans votre collection, et vous l'acceptez ou la remplacez expressément vous-même. Veuillez ne photographier que la boîte : pas de personnes, d'adresses ni d'autres informations à caractère personnel, et uniquement des images que vous êtes autorisé à soumettre.

Base juridique : article 6, paragraphe 1, point a), du RGPD — votre consentement, que vous donnez avec chaque demande individuelle. Il est facultatif ; sans lui, aucune photo n'est transmise et la question de l'état reste une indication que vous fournissez vous-même. Vous le retirez pour l'avenir en ne demandant pas d'autre évaluation. Il ne constitue pas un consentement à un entraînement ; une adhésion (opt-in) ultérieure, révocable séparément, serait une déclaration distincte.

8.7 Demandes d'assistance

Il existe un formulaire d'assistance sur la page d'assistance, et vous pouvez l'utiliser sans compte et sans connexion. Il demande une adresse e-mail pour la réponse, un objet et votre message ; le nom est facultatif. La langue n'est pas demandée — elle découle de la langue dans laquelle la page a été affichée, afin que la réponse vous parvienne dans la langue dans laquelle vous avez posé votre question. Si vous nous écrivez plutôt à l'adresse indiquée à la section 2, vous nous joignez tout aussi bien, mais cela ne crée pas de ticket ; ce message est alors simplement un e-mail dans notre boîte aux lettres.

Ce que vous envoyez est stocké sous la forme d'un ticket doté d'un numéro de ticket : l'adresse e-mail pour la réponse, le nom facultatif, la langue dans laquelle vous avez écrit, l'objet, le texte de votre demande, son état d'avancement, la voie par laquelle elle nous est parvenue, ainsi que les moments de sa réception et de sa clôture.

Aucun ticket n'est lié à un compte utilisateur dans cette version — pas même celui que vous envoyez en étant connecté. La route qui reçoit le formulaire est ouverte à tous et ne constate aucune connexion, de sorte que le champ prévu pour ce lien reste vide. Ce qui en découle pour vos droits figure ci-dessous, dans le paragraphe relatif à l'effacement. Un ticket comporte en outre un champ pour une clé d'accès à une page de statut, et aucune clé de ce type n'est émise dans cette version non plus, de sorte que ce champ reste vide lui aussi. Si une clé était émise, seule sa somme de contrôle serait stockée, jamais la clé elle-même.

Quelqu'un en est informé immédiatement. Une demande que vous déposez est signalée par e-mail à notre propre boîte aux lettres, afin qu'elle ne puisse pas rester inaperçue. Cette notification contient le numéro de ticket, l'adresse et le nom que vous avez indiqués, votre objet et le texte intégral de votre message. Elle est envoyée par l'intermédiaire du prestataire d'envoi mentionné à la section 7.3, de sorte que ces informations sont traitées aux États-Unis sur la base qui y est décrite. Contrairement aux e-mails relatifs au compte visés dans cette section, elle ne contient ni image invisible ni liens redirigés. Ce que vous voyez vous-même est votre numéro de ticket, sur la page, une fois le formulaire envoyé ; notre réponse est un e-mail distinct, voir "Comment nous répondons" ci-dessous.

Protection contre les envois en masse. Afin que le formulaire ne puisse pas être utilisé pour nous submerger, BrickDb autorise cinq envois par connexion Internet au cours d'un quart d'heure glissant. À cette fin, il détient une forme abrégée de votre adresse IP comme clé dans la mémoire vive d'un processus web — pour IPv6, la seule partie réseau, pour IPv4, l'adresse. Elle n'est pas journalisée, pas inscrite dans le ticket, pas stockée dans la base de données et pas communiquée, et elle n'influence plus aucune décision une fois le quart d'heure écoulé. Au plus 1 024 clés de ce type sont détenues ; lorsque toutes les places sont occupées, une nouvelle clé est rejetée au lieu d'en évincer une existante. Il n'y a pas de captcha, et rien n'est chargé auprès de tiers à cette fin. Base juridique : article 6, paragraphe 1, point f), du RGPD. L'intérêt légitime est la disponibilité techniquement irréprochable, sûre et équitable du service.

Base juridique : traitement de votre demande et réponse à celle-ci (article 6, paragraphe 1, point b), du RGPD dans la mesure où elle concerne votre relation d'utilisation, sinon article 6, paragraphe 1, point f), du RGPD — notre intérêt légitime à pouvoir répondre aux demandes concernant ce service). Vous pouvez vous opposer à un traitement fondé sur des intérêts légitimes en utilisant les coordonnées indiquées à la section 2.

Durée de conservation : un ticket clôturé est supprimé 24 mois après sa clôture. Le délai court à compter de la clôture et non de la réception — un ticket pour lequel vous attendez encore une réponse n'est pas supprimé, quelle que soit son ancienneté. La suppression a lieu dans le cadre d'un nettoyage périodique et peut donc intervenir quelques jours après l'expiration du délai, jamais avant. La section 13 s'applique aux copies de sauvegarde.

Lors de l'effacement du compte au titre de l'article 17 du RGPD, la suppression de votre compte sur la page du compte anonymise tous les tickets liés à votre compte : l'adresse e-mail, le nom et ce lien sont supprimés et la clé d'accès cesse d'être valable, tandis que le ticket lui-même est anonymisé au lieu d'être supprimé, parce que l'objet, le texte et nos réponses constituent notre propre trace d'une conversation à laquelle nous avons nous aussi pris part. Comme aucun ticket ne comporte un tel lien dans cette version, cette étape reste en pratique sans effet : une demande d'assistance ne figure ni dans l'export de données au titre de l'article 15 du RGPD ni dans l'effacement du compte sur la page du compte, que vous ayez été connecté ou non au moment de son envoi. La liste de ce que l'export ne contient pas mentionne les demandes d'assistance précisément pour cette raison.

Vos droits prévus à la section 14 demeurent inchangés, et voici comment les exercer pour un ticket : écrivez-nous en utilisant les coordonnées indiquées à la section 2 et indiquez le numéro de ticket ou l'adresse que vous avez utilisée. Une chose à savoir à cet égard — la suppression de champs n'anonymise pas un texte libre. Si vous avez écrit dans la demande elle-même votre nom, un numéro de commande ou d'autres informations vous concernant, celles-ci figurent toujours dans le texte. Faites-le-nous savoir si tel est le cas ; nous caviarderons ou supprimerons alors manuellement le ticket concerné.

Notes internes : pendant le traitement d'un ticket, nous rédigeons en outre des notes à notre propre usage à son sujet — ce qui a été tenté, ce que nous avons constaté, dans quel état d'avancement nous avons placé le ticket et qui l'a fait. Ces notes sont les nôtres et non les vôtres : elles sont rattachées à la personne qui les a rédigées, elles ne font jamais partie d'une réponse qui vous est adressée, et elles ne figurent donc ni dans votre export de données au titre de l'article 15 du RGPD, ni ne sont anonymisées lors de l'effacement de votre compte. Elles sont supprimées en même temps que le ticket, dans le même délai. Si vous souhaitez savoir si une note vous désigne nommément, écrivez-nous en utilisant les coordonnées indiquées à la section 2 et indiquez le numéro de ticket.

Comment nous répondons : nous répondons par e-mail à l'adresse que vous avez indiquée, dans la langue dans laquelle vous avez écrit. Cette réponse cite de nouveau votre objet et votre message afin que vous puissiez retrouver le ticket, car vous ne recevez aucune copie de la demande lors de son envoi. Notre réponse ne contient ni lien ni suivi — rien n'y est chargé depuis où que ce soit, et nous ne savons pas si vous l'ouvrez. S'il reste ensuite un point en suspens, répondez simplement à cet e-mail et laissez le numéro de ticket dans l'objet.

E-mails adressés à l'adresse d'assistance : les e-mails adressés à support@brickdb.net — y compris une réponse à l'une de nos réponses, qui doit y être envoyée — deviennent un ticket. Notre prestataire d'envoi (section 7.3) les reçoit pour notre compte pour le sous-domaine support.brickdb.net et les remet à BrickDb ; ils sont donc traités aux États-Unis sur la base qui y est décrite. Un e-mail dont l'objet comporte le numéro d'un ticket ouvert, qui provient de l'adresse propre à ce ticket, et que le domaine de l'expéditeur a signé ou autorisé (DKIM ou SPF, vérifiés à la réception) est ajouté à ce ticket ; tout autre e-mail en ouvre un nouveau, et le ticket consigne si l'expéditeur a pu être vérifié de cette manière. Sont stockés l'adresse et le nom de l'expéditeur, l'objet, la langue que l'e-mail déclare et son texte — jamais ses pièces jointes : une pièce jointe n'est stockée nulle part, et le ticket consigne seulement leur nombre. Un e-mail que notre contrôle antispam classe comme spam, qui provient de l'une de nos propres adresses, ou qui arrive après que cinq e-mails du même expéditeur (ou soixante au total) ont déjà été acceptés au cours de la dernière heure, ne devient pas un ticket ; afin qu'une demande réelle ainsi retenue puisse néanmoins être retrouvée et recevoir une réponse, nous en conservons une brève trace — le moment de son arrivée, la raison de son refus, l'adresse de l'expéditeur et l'objet, jamais le texte — pendant 30 jours. La base juridique, la durée de conservation et vos droits sont pour le reste ceux du formulaire ci-dessus.

État de la présente version : le formulaire de demande d'assistance sur /support est en service, de même que la réponse par e-mail décrite ci-dessus. Vous pouvez toujours nous joindre aussi au moyen des coordonnées indiquées à la section 2 et dans l'Impressum — c'est la voie à suivre si le formulaire refuse votre demande pour une raison quelconque.

8.8 Signalements de contenus

Chaque événement de la page des événements comporte un formulaire de signalement, de même que la page de chaque collection publiée (section 8.1a). Vous pouvez l'utiliser sans compte et sans connexion — ce sur quoi porte un signalement est un contenu qu'un visiteur non connecté peut voir, de sorte qu'un obstacle placé devant lui exclurait précisément la personne pour laquelle il existe. Le formulaire demande un motif tiré d'une liste fixe, une description facultative de ce qui ne va pas, et une adresse e-mail facultative. Un seul motif — „Autre chose“ — rend la description obligatoire, parce qu'un signalement dont tout le contenu se résume à ces mots devrait être lu avant de pouvoir être classé. La langue n'est pas demandée — elle découle de la langue dans laquelle la page a été affichée.

Ce que vous envoyez est stocké sous la forme d'un signalement doté d'une référence propre, qui ressemble à BDR-000042 : le type de contenu concerné et la clé propre à ce contenu, le motif que vous avez choisi, votre description si vous en avez rédigé une, l'adresse e-mail si vous en avez indiqué une, la langue dans laquelle vous avez écrit, l'état d'avancement du signalement, ainsi que les moments de sa réception et de la décision. Une description peut compter au plus 2 000 caractères et une adresse au plus 254 ; tout ce qui est plus long est rejeté avec indication du champ, au lieu d'être stocké sous une forme tronquée.

Aucun signalement n'est lié à un compte utilisateur — pas même celui que vous envoyez en étant connecté. La route qui reçoit le formulaire est ouverte à tous et ne constate aucune connexion, et il n'existe aucun champ pour un tel lien : BrickDb ignore délibérément quel signalement était le vôtre. Ce qui en découle pour vos droits figure ci-dessous, dans le paragraphe relatif à l'export et à l'effacement. Il n'existe en outre aucune page de statut pour un signalement ni aucune clé d'accès à une telle page, de sorte que rien de tel n'est stocké non plus.

Quelqu'un en est informé immédiatement. Un signalement que vous envoyez nous est signalé par e-mail, à notre propre boîte aux lettres, afin qu'il ne puisse pas rester inaperçu. Cette notification contient la référence, le type de contenu, le motif, la clé du contenu signalé et le texte intégral de votre description. Elle ne contient aucune adresse vous appartenant : le message nous est adressé, et votre adresse reste dans la file d'attente, où seul un administrateur peut la voir. Elle est envoyée par l'intermédiaire du prestataire d'envoi mentionné à la section 7.3, de sorte que ces informations sont traitées aux États-Unis sur la base qui y est décrite ; comme la notification d'assistance, elle ne contient ni image invisible ni liens redirigés. Ce que vous voyez vous-même est la référence, sur la page, une fois le formulaire envoyé.

Protection contre les envois en masse. Afin que le formulaire ne puisse pas être utilisé pour nous submerger, BrickDb autorise quatre signalements par connexion Internet au cours de dix minutes glissantes. À cette fin, il détient une forme abrégée de votre adresse IP comme clé dans la mémoire vive d'un processus web — pour IPv6, la seule partie réseau, pour IPv4, l'adresse. Elle n'est pas journalisée, pas inscrite dans le signalement, pas stockée dans la base de données et pas communiquée, et elle n'influence plus aucune décision une fois les dix minutes écoulées. Au plus 1 024 clés de ce type sont détenues ; lorsque toutes les places sont occupées, une nouvelle clé est rejetée au lieu d'en évincer une existante. Il n'y a pas de captcha, et rien n'est chargé auprès de tiers à cette fin. Base juridique : article 6, paragraphe 1, point f), du RGPD. L'intérêt légitime est la disponibilité techniquement irréprochable, sûre et équitable du service.

Qui lit un signalement, et ce que produit la décision. Un signalement arrive dans une file d'attente sous /admin/reports que seul un administrateur peut ouvrir ; il n'existe aucune page sur laquelle quelqu'un d'autre pourrait consulter un signalement, pas même au moyen de sa référence. Le signalement est soit rejeté, soit accueilli, et s'il est accueilli, le contenu signalé est retiré : un événement contre lequel un signalement aboutit disparaît du calendrier public. Une collection publiée contre laquelle un signalement aboutit est remise en mode privé : dès lors, seuls ses membres la voient, rien n'y est supprimé, et son propriétaire peut la publier de nouveau — une collection publiée de nouveau peut être signalée de nouveau. Nous agissons contre le contenu, non contre la personne qui l'a mis en ligne.

Une décision portant sur quelque chose qu'une personne a publié est également consignée auprès d'elle. Lorsque l'administration accueille ou rejette un signalement relatif à une collection, ou à un événement soumis par un membre, la décision est consignée dans le journal d'audit décrit à la section 8.9, auprès du compte de la personne qui a publié le contenu : de quel signalement il s'agissait, le type de contenu et sa clé, et la manière dont l'état du signalement a évolué. L'auteur du signalement n'est pas nommé dans cette entrée, et les notes de la modération n'en font pas partie non plus.

Base juridique : article 6, paragraphe 1, point f), du RGPD. L'intérêt légitime consiste à maintenir les contenus publiés par BrickDb exempts d'éléments illicites et choquants, à pouvoir tout simplement recevoir une objection — y compris de la part de quelqu'un qui n'a pas de compte —, et à pouvoir démontrer après coup comment une réclamation a été traitée. Lorsqu'un signalement concerne des contenus contre lesquels nous sommes tenus d'intervenir, son traitement sert également au respect d'une obligation légale (article 6, paragraphe 1, point c), du RGPD). Vous pouvez vous opposer à un traitement fondé sur des intérêts légitimes en utilisant les coordonnées indiquées à la section 2.

Lorsqu'un signalement est accueilli, la personne qui a publié le contenu reçoit de notre part un exposé des motifs par e-mail. Cela vaut pour une collection publiée et pour un événement soumis par un membre ; pour un événement que nous avons repris du calendrier d'un tiers, il n'y a personne à qui nous pourrions écrire. Le message indique la référence du signalement, le contenu concerné (son type et son titre ou son nom), ce que nous avons fait et pour combien de temps, le motif sous lequel le signalement a été déposé, la section de nos Conditions d'utilisation en vertu de laquelle nous avons décidé, le fait qu'aucun moyen automatisé n'a été utilisé, et la manière dont vous pouvez contester — en répondant à l'e-mail ou au moyen du formulaire d'assistance, en indiquant la référence. Il n'indique pas qui a envoyé le signalement, et il ne contient ni la description du signalement ni les notes de la modération.

Pour l'envoi, nous demandons à Auth0, au moment de la décision, votre adresse e-mail et la langue enregistrée avec votre compte (section 7.1). L'adresse n'est utilisée qu'à cette fin et n'est pas stockée chez nous ; nous consignons seulement, sur le signalement, si l'exposé des motifs a pu être envoyé et quand — ou pourquoi il ne l'a pas été, par exemple parce qu'aucune adresse n'est enregistrée. Il est envoyé par l'intermédiaire du prestataire d'envoi mentionné à la section 7.3, de sorte que ces informations sont traitées aux États-Unis sur la base qui y est décrite ; il ne contient ni image invisible ni liens redirigés. Lorsqu'une collection est remise en mode privé, le réglage modifié est en outre visible sur la page des collections. Base juridique : article 6, paragraphe 1, point c), du RGPD, en liaison avec l'article 17 du règlement (UE) 2022/2065 (règlement sur les services numériques), dans la mesure où nous sommes tenus de fournir un tel exposé des motifs, et pour le reste article 6, paragraphe 1, point f), du RGPD — l'intérêt légitime consiste à vous dire ce qu'il est advenu de votre contenu et pourquoi, et à vous donner un moyen de contester la décision.

Durée de conservation : un signalement sur lequel il a été statué est supprimé 24 mois après la décision. Le délai court à compter de la décision et non de la réception — un signalement sur lequel personne n'a encore statué n'est pas supprimé, quelle que soit son ancienneté, car il constitue une objection à laquelle une réponse est encore due. La suppression a lieu dans le cadre d'un nettoyage périodique et peut donc intervenir quelques jours après l'expiration du délai, jamais avant. La section 13 s'applique aux copies de sauvegarde.

Ni l'export de données au titre de l'article 15 du RGPD ni l'effacement du compte n'atteignent un signalement, et il s'agit d'une limite, non d'une décision prise contre vous. Comme aucun signalement n'est rattaché à un compte, il est impossible de demander quels signalements émanent d'une personne donnée — un signalement ne figure donc ni dans l'export de données au titre de l'article 15 du RGPD ni dans l'effacement du compte sur la page du compte, que vous ayez été connecté ou non au moment de son envoi, et la suppression de votre compte ne le supprime pas. Il en va de même si quelqu'un a signalé quelque chose que vous avez mis en ligne : ce signalement désigne le contenu, jamais votre compte, et ne figure donc pas non plus dans votre export — la décision le concernant y figure en revanche, dès que l'administration l'a accueilli ou rejeté, sous la forme d'une entrée du journal d'audit visé à la section 8.9. La liste de ce que l'export ne contient pas mentionne les deux cas précisément pour cette raison. Ce que vous pouvez effectivement faire : écrivez-nous en utilisant les coordonnées indiquées à la section 2 et indiquez la référence. Grâce à elle, nous pouvons retrouver le signalement manuellement, vous dire ce qu'il contient, le rectifier, ou supprimer l'adresse et le texte que vous avez écrit.

La suppression de champs n'anonymise pas un texte libre. Si vous avez écrit dans la description votre nom, une adresse ou d'autres informations vous concernant, celles-ci figurent toujours dans le texte. Faites-le-nous savoir si tel est le cas ; nous caviarderons ou supprimerons alors manuellement le signalement concerné.

Notes internes : pendant le traitement d'un signalement, nous rédigeons en outre des notes à notre propre usage à son sujet — ce que nous avons constaté, dans quel état d'avancement nous avons placé le signalement et qui l'a fait. Ces notes sont les nôtres et non les vôtres : elles sont rattachées à la personne qui les a rédigées, elles ne sont envoyées ni à vous ni à la personne dont le contenu a été signalé, et elles ne figurent donc ni dans votre export de données au titre de l'article 15 du RGPD, ni ne sont atteintes par un effacement de compte. Elles sont supprimées en même temps que le signalement, dans le même délai. Si vous souhaitez savoir si une note vous désigne nommément, écrivez-nous en utilisant les coordonnées indiquées à la section 2.

Nous ne répondons pas de notre propre initiative. Un signalement ne donne lieu à aucune correspondance : il n'y a ni e-mail de confirmation, ni page de statut, ni message lorsqu'il a été statué. L'adresse sert à ce que quelqu'un puisse vous recontacter si le signalement ne peut pas être traité sans une question à vous poser, et elle n'est utilisée pour rien d'autre. Ce que vous recevez est la référence, sur la page, immédiatement.

État de la présente version : le formulaire de signalement sur /events et sur la page de chaque collection publiée est en service, de même que la file d'attente qui se trouve derrière. S'il refuse votre signalement pour une raison quelconque, vous nous joignez tout aussi bien au moyen des coordonnées indiquées à la section 2 et dans l'Impressum — un message envoyé de cette manière est alors simplement un e-mail dans notre boîte aux lettres et ne crée aucun signalement.

8.9 Administration des comptes utilisateur

Les administrateurs de BrickDb peuvent gérer les comptes utilisateur dans un espace sous /admin/users qu'eux seuls peuvent ouvrir : voir la liste des comptes, consulter un compte, modifier son nom, son adresse e-mail, son profil ou ses rôles, envoyer une réinitialisation de mot de passe, renvoyer l'e-mail de confirmation, marquer une adresse e-mail comme confirmée, le bloquer ou le débloquer, ou le supprimer au moyen du même effacement que celui décrit à la section 14. Les données de compte qui y sont affichées sont lues en direct chez Auth0 (sections 7.1 et 7.2) et ne sont pas copiées dans la base de données de BrickDb. Il en va de même pour l'historique de connexion d'un compte : il est lu chez Auth0 lorsqu'un administrateur l'ouvre et n'est conservé qu'aussi longtemps qu'Auth0 lui-même le conserve.

Ce que l'administration voit à propos d'un compte. La page d'un compte montre ce qu'Auth0 détient à son sujet — son identifiant, l'adresse e-mail et le fait qu'elle soit confirmée ou non, les méthodes de connexion qui y sont liées, le moment où il a été créé, modifié pour la dernière fois et connecté pour la dernière fois, le nombre de fois où il s'est connecté, s'il est bloqué, quels types d'authentification multifacteur sont configurés (le type seulement, jamais un secret ni un numéro de téléphone) et ses rôles — ainsi que le profil que vous avez rempli (noms, pays, le texte à propos de vous, l'avatar choisi et la langue de vos e-mails, mais pas votre adresse postale). De la propre base de données de BrickDb, elle ne montre que des nombres : combien de collections vous possédez et combien vous en avez rejoint, combien d'exemplaires vous avez ajoutés, combien de codes de sachet, de codes-barres de sets et d'événements vous avez apportés, combien de vos demandes d'assistance sont ouvertes et combien de signalements de contenus ont été déposés avec votre adresse e-mail — jamais leur contenu.

L'historique de connexion montre, pour chaque événement qu'Auth0 a consigné pour le compte, quand il a eu lieu, ce qu'il était (une connexion ou une connexion échouée, une inscription, une déconnexion, une modification du mot de passe ou de l'adresse e-mail, une confirmation d'adresse e-mail, une étape d'authentification multifacteur, une tentative bloquée par Auth0, ou un mot de passe issu d'une fuite de données), par quelle méthode de connexion et quelle application de BrickDb il est passé, le pays et la ville qu'Auth0 a déduits de l'adresse IP, ainsi que le navigateur et le système d'exploitation avec leur version majeure. L'adresse IP elle-même n'est pas affichée, pas plus que le texte libre qu'Auth0 joint à un événement. L'administration le consulte pour préserver la sécurité des comptes — pour reconnaître des connexions qui n'étaient pas les vôtres, ou une attaque contre votre mot de passe — et pour vous aider lorsque vous nous interrogez au sujet de votre compte.

Personne au sein de l'administration ne voit, ne choisit ni ne saisit jamais un mot de passe. Un compte qui y est créé reçoit un mot de passe aléatoire que personne ne voit, et vous recevez de BrickDb un e-mail d'invitation (envoyé comme décrit à la section 7.3) contenant un lien à usage unique, valable sept jours, pour choisir votre propre mot de passe. Une réinitialisation de mot de passe est l'e-mail propre à Auth0, avec le même type de lien. Ni le mot de passe ni le lien ne sont stockés ou journalisés par BrickDb.

Chaque action de l'administration est consignée dans un journal d'audit, et ce avant son exécution, afin qu'une action qui échoue soit consignée elle aussi : quand elle a eu lieu, qui l'a exécutée, ce qu'elle était, quel compte elle concernait (son identifiant Auth0, ainsi que l'adresse e-mail et le nom qu'il avait à ce moment-là), le motif que la personne a indiqué, quels champs ont changé avec leurs valeurs avant et après, et si elle a réussi. Un mot de passe, un lien de réinitialisation ou un jeton n'y est jamais consigné. Seule l'administration peut lire le journal, sous /admin/audit, et il ne comporte aucune fonction qui modifie ou supprime une entrée.

Base juridique : article 6, paragraphe 1, point f), du RGPD. Notre intérêt légitime consiste à préserver la sécurité des comptes et du service, à vous aider lorsque votre compte en a besoin, et à pouvoir montrer après coup ce qu'il est advenu d'un compte, par qui et pourquoi — la responsabilité que l'article 5, paragraphe 2, du RGPD exige de nous. Cela vaut pour les données de l'administration figurant dans le journal tout autant que pour les vôtres. Vous pouvez vous y opposer en utilisant les coordonnées indiquées à la section 2.

Durée de conservation : une entrée du journal d'audit est supprimée 24 mois après l'action, dans le cadre du nettoyage périodique, donc éventuellement quelques jours plus tard et jamais plus tôt. La section 13 s'applique aux copies de sauvegarde.

Si vous supprimez votre compte, les entrées qui s'y rapportent sont conservées, mais ne vous nomment plus. L'identifiant du compte est remplacé par un pseudonyme aléatoire, et l'adresse e-mail, le nom et toutes les valeurs modifiées sont supprimés ; qui a agi, ce qui a été fait et quand demeure, car c'est précisément à cela que sert l'entrée. Le motif que l'administration a noté est conservé lui aussi ; il peut vous mentionner dans son texte — faites-le-nous savoir et nous le caviarderons. Si vous faites vous-même partie de l'administration et que vous supprimez votre compte, les entrées relatives à vos actions restent inchangées.

L'administration ne supprime un compte qu'au moyen de ce même effacement (section 14), étape par étape, et seulement après avoir saisi l'adresse e-mail du compte et indiqué un motif, que le journal d'audit conserve. Nous le faisons, par exemple, lorsque vous nous demandez de supprimer un compte auquel vous ne pouvez plus vous connecter. Si vous souhaitez d'abord une copie de vos données, téléchargez votre export au titre de l'article 15 du RGPD sur la page du compte avant de nous écrire — ensuite, il ne reste plus rien à exporter. L'administration ne peut pas supprimer son propre compte par cette voie ; pour cela, il y a la page du compte, comme pour tout le monde.

L'administration peut également télécharger pour vous votre export au titre de l'article 15 du RGPD — par exemple lorsque vous nous demandez de vous l'envoyer parce que vous ne pouvez pas vous connecter. Il s'agit de la même archive que celle que vous fournit la page du compte, constituée de la même manière, et l'administration ne peut la télécharger qu'après avoir indiqué un motif. Chaque téléchargement est consigné dans le journal d'audit comme toute autre action de l'administration : qui l'a téléchargée, quand et pourquoi. L'archive est remise directement au navigateur de l'administration ; BrickDb n'en conserve aucune copie et ne l'inscrit dans aucun journal.

Votre export au titre de l'article 15 du RGPD, sur la page du compte, contient les entrées relatives à votre compte (sous „adminAuditEntries“) — quand, quoi, le motif et ce qui a changé —, mais pas quel membre de l'administration était en cause, car ce sont les données de cette personne et non les vôtres. Écrivez-nous en utilisant les coordonnées indiquées à la section 2 si vous souhaitez le savoir.

État de la présente version : la liste des utilisateurs avec sa recherche, la page d'un compte individuel, son historique de connexion, chaque action énumérée ci-dessus et le journal d'audit sont en service.

9. Sources de données externes

BrickDb affiche des données de catalogue et de prix provenant de sources tierces, en particulier Rebrickable et BrickLink. Ces données sont récupérées exclusivement côté serveur et reprises dans notre propre fonds de données. À aucun moment le navigateur n'établit de connexion avec ces fournisseurs.

Aucune donnée à caractère personnel n'est transmise à ces fournisseurs — ni adresse IP, ni identifiant, ni l'information sur ce qui a été recherché ou sur ce que quelqu'un possède. Les interrogations ont lieu selon notre propre calendrier et non comme la retransmission de la requête d'un utilisateur.

10. Mesure d'audience avec Google Analytics

BrickDb utilise Google Analytics 4 pour compter combien de fois les pages sont ouvertes et quelles rubriques sont utilisées. Cela n'a lieu qu'avec votre consentement. Tant que vous n'avez pas accepté, aucun script de Google n'est chargé, aucun identifiant n'est défini et rien n'est envoyé à Google — pas même un signal préalable dit « sans cookie ». Le mode de consentement avancé de Google ("Consent Mode v2 advanced"), dans lequel le script se charge immédiatement et transmet des données avant le consentement, n'est délibérément pas utilisé.

Base juridique : article 6, paragraphe 1, point a), du RGPD — votre consentement — ainsi que l'article 25, paragraphe 1, de la TDDDG pour le stockage et la lecture des informations sur votre équipement terminal.

Destinataire et sous-traitant : Google Ireland Limited, Gordon House, Barrow Street, Dublin 4, Irlande, sur la base des conditions de sous-traitance de Google (Google Ads Data Processing Terms), acceptées pour l'ordre juridique de l'Allemagne.

Ce qui est traité : la page ouverte et son titre, la source référente, une localisation approximative au niveau du pays et de la région, le type d'appareil, le navigateur, le système d'exploitation, la taille de l'écran et la langue, la date et l'heure, ainsi qu'un identifiant aléatoire contenu dans les cookies énumérés à la section 6.1, qui permet de reconnaître les visites répétées depuis le même navigateur. Sont en outre actifs les événements automatiques que Google appelle "mesures améliorées" : la profondeur de défilement, la recherche sur ce site, les téléchargements de fichiers, les interactions avec des vidéos et les clics sur des liens vers d'autres sites web — donc aussi sur les liens d'affiliation décrits à la section 10.1. Votre adresse IP est utilisée par Google pour en déduire la localisation approximative et, selon Google, n'est ce faisant ni journalisée ni stockée.

Ce qui n'a pas lieu : les fonctions "signaux Google" et "publicité personnalisée" sont expressément désactivées dans le code source de la page (allow_google_signals et allow_ad_personalization_signals sont tous deux sur false), et le partage avec les "produits et services Google" est désactivé dans la propriété. Aucune liste publicitaire ou d'audience n'est constituée, aucune donnée n'est transmise à Google à des fins publicitaires, et aucun profil inter-appareils n'est créé. Il n'y a pas de prise de décision automatisée, y compris de profilage, au sens de l'article 22 du RGPD. Aucun autre service d'analyse, aucun réseau publicitaire et aucun module de réseau social n'est intégré à la page, pas plus qu'un script d'un service de rapports d'erreurs : le navigateur ne charge rien depuis un tel service et ne lui envoie rien. Le diagnostic d'erreurs que BrickDb utilise effectivement fonctionne sur le serveur et — dans l'application — sur l'appareil lui-même ; il est décrit à la section 11.

Transfert vers des pays tiers : le cocontractant est Google Ireland Limited ; un transfert à Google LLC aux États-Unis ne peut être exclu. Google LLC est certifiée au titre de l'EU-US Data Privacy Framework, pour lequel la Commission européenne a adopté une décision d'adéquation le 10 juillet 2023 ; les clauses contractuelles types figurant dans les conditions de sous-traitance de Google s'appliquent à titre complémentaire.

Durée de conservation : les données relatives aux événements et aux utilisateurs sont conservées dans la propriété Google Analytics jusqu'à 14 mois à compter de votre dernière interaction, puis sont supprimées par Google. Le délai court à compter de la dernière visite et non de la première, parce que l'option "réinitialiser en cas de nouvelle activité" est active dans la propriété : chaque nouvelle visite fait repartir les 14 mois. Les données de quiconque revient régulièrement ne sont donc pas supprimées tant qu'il revient. Sont concernées les données rattachées à des événements et à des identifiants individuels. Les rapports standard agrégés — par exemple "combien de pages vues y a-t-il eu en septembre" — ne sont pas visés par ce réglage et restent disponibles chez Google au-delà. Le cookie de consentement sur votre appareil expire après 182 jours ; la question est ensuite posée de nouveau.

Retrait du consentement : au bas de chaque page se trouve la rubrique "Mesure d'audience", avec un bouton qui inverse votre décision — un clic, exactement comme l'était l'acceptation (article 7, paragraphe 3, du RGPD). Le retrait prend effet immédiatement : le script n'est plus chargé, et les cookies déposés par Google (_ga et _ga_…) sont supprimés avec la même requête. La licéité du traitement effectué avant le retrait n'en est pas affectée. Pour les données déjà transmises à Google, vous pouvez en outre exercer les droits décrits à la section 14.

Ce que cela signifie pour les chiffres : seules les personnes qui ont accepté sont comptées. Les chiffres sont donc incomplets et inférieurs à l'utilisation réelle. C'est la conséquence voulue de la décision de ne rien charger sans consentement.

10.1 Liens d'affiliation

BrickDb participe à des programmes d'affiliation ; les liens concernés portent directement la mention "Publicité". Cela ne change rien à ce qui est dit ci-dessus : aucun réseau publicitaire n'est intégré à la page, aucun script ni pixel de comptage d'un réseau d'affiliation n'est chargé, et aucun identifiant n'est défini. La simple ouverture d'une page ne déclenche rien de tel.

Ce n'est que lorsqu'une personne clique sur un tel lien que son navigateur se rend à l'adresse du marchand ou du réseau d'affiliation. Il s'agit d'un changement de page que la personne a elle-même déclenché, et dont le site de destination est le responsable du traitement au regard de la protection des données. L'adresse contient un identifiant qui indique au marchand que la visite provient de BrickDb ; il est visible dans la barre d'adresse. BrickDb n'apprend pas qui a cliqué : le réseau d'affiliation fournit uniquement des données de décompte agrégées, et aucune donnée à caractère personnel sur des clics individuels.

Awin. Les liens vers les marchands dont BrickDb reprend les prix à partir d'un flux de données produits d'Awin passent par le réseau d'affiliation Awin (AWIN AG, Berlin). BrickDb restitue un tel lien sans le modifier, exactement tel que le flux le fournit : il contient l'identifiant d'éditeur de BrickDb, l'identifiant du marchand et la destination chez le marchand, et rien à votre sujet - ni identifiant de compte, ni identifiant de clic ou de visiteur attribué par BrickDb. Lorsque vous cliquez dessus, votre navigateur se rend d'abord à une adresse d'Awin (awin1.com) et est redirigé de là vers le marchand. Ce faisant, Awin peut collecter des informations directement auprès de vous et déposer ou lire des cookies dans votre navigateur sur son propre domaine, afin d'attribuer un achat ultérieur à ce clic, conformément à la politique de confidentialité propre à Awin. BrickDb ne dépose aucun cookie à cette fin, n'enregistre pas le clic sur son propre serveur et ne transmet lui-même aucune donnée vous concernant à Awin.

Rakuten Advertising. Les liens vers les boutiques en ligne que LEGO exploite lui-même, et dont BrickDb reprend les prix à partir d'un flux de données produits de Rakuten Advertising, passent par le réseau d'affiliation Rakuten Advertising, de même que le lien vers la carte cadeau LEGO chez Giftcards.com qu'une page de set propose aux visiteurs aux États-Unis. Le responsable du traitement est Rakuten Marketing LLC dba Rakuten Advertising, 800 Concar Drive, Suite 175, San Mateo, CA 94402, USA, qui déclare l'être également pour les visiteurs du Royaume-Uni et de l'Espace économique européen. Aux fins de sa politique de confidentialité, Rakuten Advertising désigne Rakuten Advertising France S.A.S, 92 rue Réaumur, 75002 Paris, France, comme son établissement dans l'UE et Rakuten Marketing Europe Limited, Vintners Place, 68 Upper Thames St., London EC4V 2AF, Royaume-Uni, comme son établissement au Royaume-Uni. BrickDb restitue ce lien lui aussi sans le modifier, exactement tel que le flux de données produits le fournit : il contient l'identifiant d'éditeur de BrickDb, un identifiant d'offre et l'adresse de destination dans la boutique, et rien à votre sujet. Le lien vers la carte cadeau LEGO ne provient pas du flux de données produits : Rakuten Advertising l'a généré une seule fois pour BrickDb, et il contient de même uniquement l'identifiant d'éditeur de BrickDb, l'identifiant de Giftcards.com et l'adresse de destination chez Giftcards.com. Lorsque vous cliquez sur un lien, votre navigateur se rend d'abord à une adresse de Rakuten Advertising (click.linksynergy.com) et est redirigé de là vers la boutique. Ce faisant, Rakuten Advertising peut collecter des informations directement auprès de vous et déposer ou lire des cookies dans votre navigateur sur son propre domaine, afin d'attribuer un achat ultérieur à ce clic, conformément à la politique de confidentialité propre à Rakuten Advertising. Vous pouvez exercer vos droits à l'égard de Rakuten Advertising au moyen de son formulaire de demande relative à la protection des données ; ses possibilités de contact se trouvent ici. BrickDb ne dépose aucun cookie à cette fin, n'enregistre pas le clic sur son propre serveur et ne transmet lui-même aucune donnée vous concernant à Rakuten Advertising.

Tradedoubler. Les liens vers la librairie Hugendubel, dont BrickDb reprend les prix à partir d'un flux de données produits de Tradedoubler, passent par le réseau d'affiliation Tradedoubler. Selon la politique de confidentialité propre à Tradedoubler, le responsable du traitement est Nyorda AB (Suède), la société mère du groupe Tradedoubler. BrickDb restitue ce lien lui aussi sans le modifier, exactement tel que le flux de données produits le fournit : il contient l'identifiant d'éditeur de BrickDb, les identifiants du programme et du produit et l'adresse de destination chez Hugendubel, et rien à votre sujet. Lorsque vous cliquez dessus, votre navigateur se rend d'abord à une adresse de Tradedoubler (pdt.tradedoubler.com) et est redirigé de là vers Hugendubel. Ce faisant, Tradedoubler peut collecter des informations directement auprès de vous et déposer ou lire des cookies dans votre navigateur sur son propre domaine, afin d'attribuer un achat ultérieur à ce clic, conformément à la politique de confidentialité propre à Tradedoubler. Vous pouvez exercer vos droits à l'égard de Tradedoubler à l'adresse privacy@tradedoubler.com. BrickDb ne dépose aucun cookie à cette fin, n'enregistre pas le clic sur son propre serveur et ne transmet lui-même aucune donnée vous concernant à Tradedoubler.

Amazon. En tant que Partenaire Amazon, je réalise un bénéfice sur les achats remplissant les conditions requises. BrickDb participe aux programmes Partenaires Amazon pour amazon.com (exploité par Amazon.com Services LLC) et amazon.de (exploité par Amazon Europe Core S.à r.l.). Une page de set renvoie à une recherche dans la boutique Amazon concernée ; rien d'Amazon n'est chargé sur BrickDb - ni script, ni image, ni prix, ni logo. Dès que vous suivez un tel lien, vous êtes sur le propre site d'Amazon, où Amazon peut collecter des informations directement auprès de vous et déposer ou lire des cookies dans votre navigateur, conformément à la politique de confidentialité propre à Amazon. BrickDb ne reçoit d'Amazon que des rapports agrégés, et aucune donnée sur des visiteurs individuels.

Un ajout depuis la mesure d'audience : si vous l'avez acceptée conformément à la section 10, le clic sur un tel lien est en outre compté comme un événement dans Google Analytics — avec l'adresse de destination, sans indication permettant de savoir qui a cliqué, hormis l'identifiant aléatoire qui y est décrit. Sans votre consentement, cela n'a pas lieu non plus.

11. Surveillance de l'exploitation et diagnostic d'erreurs

L'application est instrumentée avec OpenTelemetry. Ces données ne sont exportées que si une destination est expressément configurée ; en exploitation, aucune destination de ce type n'est configurée, de sorte que ces données de télémétrie ne quittent pas le processus. Les appels aux points de terminaison d'état sont exclus de l'enregistrement.

Pour les rapports d'erreurs, le service Sentry est en outre utilisé. Si l'application plante, ou si une requête échoue de manière inattendue sur le serveur, un rapport d'erreur est transmis à Sentry afin que l'erreur puisse être trouvée et corrigée. Cela concerne quatre endroits : le serveur API, le serveur web, le service de lecture décrit à la section 8.5 et — contrairement à tout le reste de cette section — l'application sur votre appareil. Dans les quatre cas, la connexion à Sentry est établie par l'application elle-même ; aucun script d'un service de rapports d'erreurs n'est intégré au site web, de sorte que le navigateur n'y envoie rien de lui-même (section 10).

Le fournisseur est Functional Software, Inc. d/b/a Sentry, 45 Fremont Street, 8th Floor, San Francisco, CA 94105, USA ; il est à cet égard sous-traitant au sens de l'article 28 du RGPD. Selon ses propres indications, Sentry n'a aucun établissement dans l'Union européenne avec lequel un contrat pourrait être conclu — le cocontractant est donc une société établie aux États-Unis.

Lieu de traitement : la question de savoir où se trouvent les données est distincte. Les rapports sont envoyés à la région UE de Sentry, que Sentry désigne elle-même comme European Union (EU) et qui est la région de stockage définie pour notre organisation. L'adresse de réception des quatre endroits se trouve sur ingest.de.sentry.io et non sur l'adresse mondiale du service. Ce sont deux choses différentes, et seule la seconde est un nom d'hôte : l'adresse à laquelle le logiciel envoie, par opposition au réglage du compte qui décide de l'endroit où ce qui arrive est conservé.

Transfert vers un pays tiers : comme le cocontractant est établi aux États-Unis, un accès depuis ce pays — par exemple dans le cadre de l'assistance et de la maintenance — ne peut être exclu. Sentry fonde de tels transferts sur les clauses contractuelles types de la Commission européenne, qui sous-tendent son accord de sous-traitance dans sa version 5.1.0 du 29 mai 2024.

Ce que contient un rapport d'erreur : le type de l'erreur et son message, la trace d'appels technique (fichiers, méthodes, numéros de ligne), la version de BrickDb, l'adresse demandée avec ses paramètres de requête, à l'exception de ceux qui sont supprimés comme décrit ci-dessous, sur le serveur API et le serveur web également les en-têtes de la requête — par exemple l'identification de votre navigateur, la langue préférée et la page d'où vous venez — ainsi que ce que le SDK Sentry collecte de lui-même sur l'environnement — en particulier le modèle de l'appareil, le système d'exploitation et sa version, la langue et le fuseau horaire. Sur le serveur API s'ajoute l'identifiant pseudonyme de votre compte si vous étiez connecté ; le serveur web et l'application ne transmettent aucun identifiant du tout.

Ce que signale le service de lecture : le service de lecture décrit à la section 8.5 n'envoie un rapport d'erreur que lorsque la lecture d'une photo échoue de manière inattendue ; il ne signale pas le fait qu'il est saturé ou qu'il rejette une photo. Un tel rapport contient le type de l'erreur et son message, la trace d'appels technique, la version de BrickDb, l'adresse interne à laquelle le serveur API l'a appelé, les en-têtes de cet appel interne — et non ceux de votre navigateur — et les informations sur l'environnement du serveur. Le service de lecture ne transmet aucun identifiant de votre compte. La photo soumise n'est jamais contenue dans un rapport du service de lecture, pas même en partie : le contenu d'une requête n'est pas capturé, et le service de lecture ne journalise rien au sujet de la photo.

Ce que l'application consigne en plus : afin qu'une erreur survenue sur votre appareil puisse être retracée, l'application joint une trace de parcours à un rapport d'erreur. Elle contient les noms des pages ouvertes en dernier (et non leurs adresses) ; pour chaque requête à notre serveur qui n'a pas abouti, la méthode, l'adresse sous forme de modèle sans identifiants, le code d'état, la durée et, s'il est connu, le type de l'erreur ; les réglages consignés au démarrage — l'adresse du serveur sans chemin, le fait que la connexion et les rapports d'erreurs soient activés ou non, et la langue définie ; et, parce que le SDK Sentry tient sa propre trace de parcours des requêtes, pour chaque requête de l'application — à notre serveur et au service de connexion — également l'adresse complète avec la méthode et le code d'état, y compris le chemin, qui peut contenir par exemple un numéro de set ou l'identifiant d'une collection, et les paramètres de requête, par exemple un terme de recherche. De cette adresse aussi, les paramètres de requête mentionnés ci-dessus dont le nom suggère un secret, ainsi que les adresses e-mail, sont supprimés avant l'envoi. La même adresse peut en outre figurer dans une mesure de performance, que Sentry établit pour une part de 2 % des opérations de l'application, sélectionnée de manière aléatoire.

Informations sur l'appareil : chaque rapport que l'application envoie après son démarrage comporte la plateforme, la version du système d'exploitation, le type d'appareil (par exemple téléphone ou tablette) et la version de l'application ; et, dès que la vérification de l'affichage effectuée au démarrage a eu lieu, également le type et la version majeure de la vue web dans laquelle l'application fonctionne. Si l'application ne parvient pas à charger une image, une feuille de style, un script ou une police, ou bloque un contenu pour des raisons de sécurité, ce dont il s'agissait est consigné — pour nos propres fichiers, le chemin sans identifiants, pour les adresses de tiers, uniquement le nom du serveur, pour une police, son nom — et, une fois au démarrage, une vérification de l'affichage : quelles feuilles de style ont été chargées, combien de règles elles contiennent et quelle police est effectivement utilisée. Un tel échec de chargement, une erreur du serveur ou une requête qui ne reçoit aucune réponse peut déclencher un rapport distinct même sans plantage — la même erreur au plus une fois en dix minutes pour une requête, et au plus une fois par démarrage de l'application pour un échec de chargement.

Le journal sur votre appareil : l'application écrit dans un journal situé dans son propre espace de stockage : chaque requête à notre serveur — y compris chaque requête réussie — avec la méthode, l'adresse sous forme de modèle sans identifiants, le code d'état, la durée et un numéro de requête aléatoire ; les échecs de chargement mentionnés ci-dessus ; le résultat de la vérification de l'affichage effectuée au démarrage, y compris le type et la version de la vue web ; les réglages consignés au démarrage ; et les autres messages de l'application à partir du niveau "Information". Les noms des pages ouvertes, le type d'une erreur, les informations sur l'appareil et les adresses complètes issues de la propre trace de parcours de Sentry ne figurent pas dans ce journal. Il comprend au plus trois fichiers d'un mégaoctet chacun, les entrées les plus anciennes étant écrasées, et chaque entrée est nettoyée lors de son écriture de la même manière qu'un rapport d'erreur. Ce journal ne quitte pas l'appareil de lui-même. Ce n'est que si vous appuyez sur "Copier les données de diagnostic" sous "À propos" que l'application place la version de l'application, la plateforme, la version du système d'exploitation, le type d'appareil, les réglages consignés au démarrage et jusqu'à 200 des entrées les plus récentes — nettoyées une nouvelle fois — dans le presse-papiers ; c'est vous qui décidez où vous les collez.

Ce qui est expressément supprimé avant qu'un rapport ne quitte l'appareil ou le serveur : tous les cookies, l'intégralité du contenu d'une requête, chaque paramètre de requête dont le nom suggère un secret (entre autres code, state, token, password, email, key), chaque valeur d'en-tête dont le nom suggère un secret, chaque en-tête dans lequel nos serveurs placés en amont transmettent votre adresse IP, ainsi que les adresses e-mail et les chaînes de caractères ressemblant à un jeton — y compris au milieu d'un message d'erreur. Un nom d'utilisateur, une adresse e-mail ou une adresse IP figurant dans la section utilisateur du rapport est écrasé avant l'envoi du rapport, de même que l'identifiant d'installation que le SDK y inscrit de lui-même. Ce nettoyage est conçu de telle sorte qu'en cas de défaillance, il écarte le rapport au lieu de l'envoyer non filtré.

L'application elle-même ne transmet aucune adresse IP : SendDefaultPii est sur false aux quatre endroits, le nettoyage qui vient d'être décrit écrase de toute façon ce champ, et il supprime aussi les en-têtes dans lesquels nos serveurs placés en amont transmettent votre adresse IP au serveur web et au serveur API. Aucune capture d'écran n'est jointe, et les textes de l'interface utilisateur ne sont pas repris dans les traces de parcours ; les deux sont expressément désactivés. Les photos ne peuvent pas atteindre un rapport d'erreur, parce que le contenu d'une requête est de toute façon intégralement supprimé.

Mesures de performance sur le serveur : qu'une erreur survienne ou non, le serveur web, le serveur API et le service de lecture établissent une mesure de performance pour une part des requêtes sélectionnée de manière aléatoire et la transmettent à Sentry, afin que les points lents puissent être trouvés ; les appels aux points de terminaison d'état et les requêtes de contrôle de nos serveurs placés en amont en sont exclus. Cette part est de 5 %. Toutefois, si une requête provient de l'application, du serveur web ou du serveur API et qu'elle fait partie d'une opération pour laquelle il y a déjà été décidé si elle est mesurée, le serveur reprend cette décision, de sorte qu'une telle opération est mesurée soit à chaque étape, soit à aucune. Une telle mesure contient les mêmes informations sur la requête qu'un rapport d'erreur du serveur — la méthode, l'adresse demandée avec ses paramètres de requête, par exemple un terme de recherche, et les en-têtes de la requête — et, en plus, le modèle de l'adresse demandée sans identifiants, le code d'état de la réponse, le début et la durée du traitement, et les messages que l'application journalise pendant ce temps. S'y ajoutent les différentes étapes de travail avec leur durée : les requêtes que le serveur émet lui-même à cette occasion — par exemple du serveur web au serveur API, ou du serveur API au service de connexion —, chacune avec la méthode, l'adresse complète et le code d'état, et les requêtes de base de données avec leur texte, dans lequel les valeurs insérées n'apparaissent que sous forme d'espaces réservés et non comme les valeurs elles-mêmes. Sur le serveur API, la mesure comporte l'identifiant pseudonyme de votre compte si vous étiez connecté ; le serveur web et le service de lecture ne transmettent aucun identifiant. Pour le service de lecture, une mesure ne concerne que l'appel interne effectué par le serveur API ; il n'émet lui-même à cette occasion aucune requête vers d'autres serveurs ni aucune requête de base de données, et la photo n'est jamais contenue non plus dans une mesure. Chaque mesure de performance fait l'objet du même nettoyage qu'un rapport d'erreur, décrit ci-dessus ; en particulier, les cookies et les en-têtes contenant votre adresse IP sont supprimés avant l'envoi. La base juridique est l'article 6, paragraphe 1, point f), du RGPD ; l'intérêt légitime consiste à exploiter l'application de manière rapide et fiable. Sentry conserve une mesure de performance complète pendant 90 jours au plus dans notre offre ; un échantillon réduit des mesures peut être conservé par Sentry jusqu'à 13 mois.

Sentry ne conserve pas l'adresse IP de la connexion. L'envoi d'un rapport établit une connexion Internet ; l'adresse depuis laquelle il a été envoyé est donc nécessairement connue du serveur destinataire pendant la transmission. Sentry propose un réglage qui écarte cette adresse au lieu de l'enregistrer, et ce réglage est activé pour les quatre projets — ceux du serveur API, du serveur web, du service de lecture et de l'application. Un rapport d'erreur ne conserve donc pas l'adresse. Cela vaut aussi pour les rapports de l'application, pour lesquels il s'agirait de l'adresse de votre propre connexion Internet ; pour le serveur API, le serveur web et le service de lecture, il s'agirait de l'adresse de nos propres serveurs.

Pour la transmission, tout le reste de cette section s'applique sans changement : le destinataire est Functional Software, Inc. d/b/a Sentry, les rapports sont envoyés à la région de stockage mentionnée ci-dessus, et le transfert repose sur les clauses contractuelles types décrites ci-dessus. Le propre nettoyage côté serveur de Sentry est activé dans sa forme par défaut pour nos quatre projets — ceux du serveur API, du serveur web, du service de lecture et de l'application ; nous n'y avons ajouté aucune règle propre et n'avons supprimé aucune des règles de Sentry.

Base juridique : article 6, paragraphe 1, point f), du RGPD — pour le rapport d'erreur comme pour l'adresse IP lors de sa transmission. L'intérêt légitime consiste à détecter et à corriger les erreurs et les plantages. L'adresse n'est traitée pour aucune finalité propre, et elle n'est pas utilisée pour vous reconnaître. Il s'agit de la même base que celle sur laquelle la section 3 traite l'adresse IP qui est nécessairement générée lors de toute connexion au site web. Vous pouvez vous y opposer en vertu de l'article 21 du RGPD en utilisant les coordonnées indiquées à la section 2.

Durée de conservation : 90 jours. La durée pendant laquelle un rapport d'erreur est conservé chez Sentry découle de l'offre à laquelle l'organisation a souscrit. La nôtre relève de l'offre Business de Sentry, pour laquelle Sentry publie une conservation de 90 jours ; dans l'offre Developer, elle serait de 30. Les pièces jointes suivent l'événement auquel elles appartiennent. Une durée plus courte peut être définie pour un projet individuel et prévaudrait alors ; aucun de nos quatre projets n'en comporte, de sorte que les 90 jours valent de la même manière pour les quatre.

12. Destinataires

Les données à caractère personnel ne sont pas vendues et ne sont pas transmises à des fins publicitaires. Les destinataires sont actuellement Microsoft Ireland Operations Limited, en tant que sous-traitant pour l'hébergement, la base de données et le stockage de fichiers ainsi que — uniquement à votre demande expresse conformément à la section 8.6 — pour l'évaluation d'images par Azure OpenAI, et Twilio Inc. (“SendGrid”) en tant que sous-traitant pour l'envoi d'e-mails conformément à la section 7.3, y compris le traitement aux États-Unis qui y est décrit. Si vous avez accepté la mesure d'audience conformément à la section 10, Google Ireland Limited s'y ajoute comme autre sous-traitant pour la durée de cette mesure ; sans votre consentement, elle ne reçoit rien. Pour la connexion conformément à la section 7.1, Auth0 / Okta, Inc. est sous-traitant, et pour les rapports d'erreurs conformément à la section 11, Functional Software, Inc. d/b/a Sentry ; toutes deux sont établies aux États-Unis et fondent le transfert sur les clauses contractuelles types de la Commission européenne, comme décrit dans les sections mentionnées. Les informations approuvées sur les événements sont publiques comme décrit à la section 8.4 ; le lien avec le compte n'en fait pas partie. Au-delà, les données ne sont transmises que s'il existe une obligation légale de le faire.

13. Durées de conservation

• Données de collection et photos : jusqu'à leur suppression par la personne concernée ou jusqu'à la suppression du compte.
• Réglages sur l'équipement terminal : voir la section 6.1.
• Données de compte détenues par le fournisseur d'identité (sections 7.1 et 7.2) : jusqu'à la suppression du compte, qui supprime en même temps le compte chez Auth0.
• Mesure d'audience : jusqu'à 14 mois à compter de la dernière interaction pour les données relatives aux événements et aux utilisateurs chez Google, 182 jours pour le cookie de consentement sur votre appareil — voir la section 10.
• Propositions d'événements : les durées de conservation distinctes selon le statut, indiquées à la section 8.4.
• Demandes d'assistance : 24 mois après la clôture du ticket — voir la section 8.7, y compris pour la raison pour laquelle le délai court à compter de la clôture et non de la réception.
• Signalements de contenus : 24 mois après la décision — voir la section 8.8, y compris pour la raison pour laquelle le délai court à compter de la décision et non de la réception, et pour laquelle un signalement sur lequel il n'a pas encore été statué n'est pas supprimé.
• Actions de l'administration sur les comptes utilisateur (journal d'audit) : 24 mois après l'action — voir la section 8.9, y compris pour ce qui subsiste lorsque le compte est supprimé. Les données de compte et l'historique de connexion affichés à l'administration sont lus en direct chez Auth0 et ne sont pas stockés par BrickDb.
• Photos pour la lecture du numéro de set (section 8.5) et pour l'évaluation de l'état (section 8.6) : non stockées par BrickDb et écartées à la fin de la requête.
• E-mails envoyés : BrickDb n'en conserve aucune copie ; pour les données de remise détenues par le prestataire d'envoi, voir la section 7.3.
• Journaux au niveau de l'infrastructure : voir la section 3.
• Rapports d'erreurs chez Sentry : 90 jours — voir la section 11 ; Sentry ne conserve pas l'adresse IP de la connexion par laquelle ils ont été remis.
• Mesures de performance chez Sentry : complètes pendant 90 jours au plus, sous forme d'échantillon réduit pendant jusqu'à 13 mois — voir la section 11.

Lorsqu'une entrée est supprimée, les photos qui s'y rapportent sont supprimées avec elle — y compris les versions réduites décrites à la section 8. Les données supprimées disparaissent des copies de sauvegarde à l'expiration régulière de celles-ci, au plus tard après 35 jours.

14. Droits des personnes concernées

Les droits suivants existent :

• Accès aux données traitées (article 15 du RGPD),
• Rectification des données inexactes (article 16 du RGPD),
• Effacement (article 17 du RGPD),
• Limitation du traitement (article 18 du RGPD),
• Portabilité des données (article 20 du RGPD),
• Opposition aux traitements fondés sur l'article 6, paragraphe 1, point f), du RGPD (article 21 du RGPD),
• Retrait d'un consentement donné, avec effet pour l'avenir (article 7, paragraphe 3, du RGPD).

Un message sans formalité à l'adresse e-mail indiquée à la section 2 suffit pour les exercer.

Le droit d'accès prévu à l'article 15 du RGPD peut en outre être exercé directement, sans envoyer de message : la page du compte produit une copie complète et lisible par machine de toutes les données stockées vous concernant — votre compte et votre profil, vos collections avec leurs membres et les invitations que vous avez émises, les exemplaires qu'elles contiennent avec leurs notes, étiquettes, état, prix d'achat et notes sur le vendeur, les minifigurines individuelles et pièces détachées, vos exemplaires de numéros de magazines et de livres, vos emplacements de rangement et l'indication de l'exemplaire conservé dans chacun d'eux, les signatures enregistrées, votre liste de souhaits, vos contributions aux codes de sachet et aux codes-barres de boîte, vos propositions d'événements dans chaque statut de modération, les lots de photos de boîtes que vous avez soumis, les entrées du journal d'audit de l'administration relatives à votre compte (section 8.9), chaque photo que vous avez téléversée, ainsi que votre image d'avatar si vous en avez téléversé une.

Ce que cette copie ne contient pas, et pourquoi : vos données de connexion auprès du fournisseur d'identité (adresse e-mail, mot de passe, historique de connexion, seconds facteurs enregistrés) — elles sont détenues par Auth0, qui fournit à ce sujet sa propre information au titre du droit d'accès ; les invitations que d'autres personnes ont envoyées à votre adresse, parce qu'il s'agit de leurs données et non des vôtres ; la vue des pièces dérivée de vos exemplaires, parce qu'elle ne contient rien qui ne figure déjà dans la copie ; les demandes d'assistance — toutes sans exception, parce qu'aucun ticket n'est lié à un compte dans cette version et que nous ne pouvons pas reconnaître lesquelles sont les vôtres (la section 8.7 indique comment nous joindre à ce sujet) ; les notes internes relatives à une demande d'assistance, qui sont les nôtres et non les vôtres (section 8.7 également) ; la brève trace d'un e-mail adressé à l'adresse d'assistance qui n'est pas devenu un ticket, parce qu'elle n'est liée à aucun compte (section 8.7) ; les signalements de contenus, qui ne sont liés à aucun compte non plus, et les notes que nous avons rédigées en statuant sur un signalement relatif à votre contenu (section 8.8) ; quel membre de l'administration a agi sur votre compte, parce qu'il s'agit des données de cette personne et non des vôtres (section 8.9) ; et la notification mise en file d'attente pour une proposition d'événement que vous avez soumise, qui ne contient que la mécanique d'envoi et renvoie à la proposition déjà énumérée ci-dessus.

Le droit à l'effacement prévu à l'article 17 du RGPD peut lui aussi y être exercé directement. La page du compte vous montre d'abord exactement ce qui sera supprimé ; une fois confirmée, la suppression est exécutée immédiatement — votre collection, vos emplacements de rangement, vos photos (les fichiers eux-mêmes, et pas seulement les entrées) et votre compte de connexion auprès du fournisseur d'identité. Elle est irréversible.

Les exceptions sont délibérément réglées ainsi ; pour les événements, la section 8.4 s'applique. Vos contributions aux codes de sachet sont anonymisées au lieu d'être supprimées : la figurine que contient un sachet est un fait relatif à un produit LEGO que d'autres utilisateurs ont établi ensemble et auquel ils se fient — la contribution demeure, et le lien avec vous est remplacé par une valeur aléatoire nouvellement tirée, pour laquelle il n'existe plus ni compte ni correspondance (considérant 26 du RGPD). Un exemplaire que vous avez placé dans une collection partagée avec d'autres personnes est de même anonymisé au lieu d'être supprimé : le supprimer priverait les autres participants de leur entrée relative à un set tenu en commun. Le numéro de set, la quantité et l'état restent donc attachés à la collection, tandis que tout ce qu'il comporte de personnel disparaît — le surnom que vous lui avez donné, vos notes, vos étiquettes, son lieu de rangement, le prix que vous avez payé, la valeur que vous lui attribuiez et ses photos — en même temps que le lien avec vous, remplacé par une valeur aléatoire nouvellement tirée de la même manière. Un exemplaire dans une collection dont personne d'autre ne fait partie est entièrement supprimé, car il n'y a personne à qui il serait retiré. Et les copies de sauvegarde continuent de suivre la section 13 : les données supprimées en disparaissent à leur expiration régulière, au plus tard après 35 jours.

Les différentes étapes, une énumération de ce qui est supprimé et de ce qui est conservé sous une forme anonymisée, et la voie à suivre pour les personnes qui ne peuvent plus se connecter sont résumées sur la page Suppression du compte et des données. Elle est accessible sans connexion et ne fait que reprendre ce qui figure dans la présente section.

Droit d'introduire une réclamation

Indépendamment de cela, il existe, en vertu de l'article 77 du RGPD, un droit d'introduire une réclamation auprès d'une autorité de contrôle, en particulier dans l'État membre de la résidence habituelle, du lieu de travail ou du lieu de la violation alléguée. L'autorité compétente pour le responsable du traitement est :

Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen
Postfach 20 04 44
40102 Düsseldorf
Téléphone : +49 211 38424-0
E-mail : poststelle@ldi.nrw.de
www.ldi.nrw.de

15. Obligation de fournir des données

La fourniture de données n'est exigée ni par la loi ni par un contrat. Sans indications, toutefois, les fonctions de collection ne peuvent pas être utilisées utilement ; les parties librement accessibles du service sont ouvertes sans aucune indication.

16. Modifications et version linguistique faisant foi

La présente politique sera adaptée si le traitement ou la situation juridique change. La version publiée ici à un moment donné, portant la date indiquée ci-dessus, est celle qui fait foi.

La version allemande fait foi. Les versions en anglais, en français, en néerlandais, en danois, en italien et en espagnol sont des traductions fournies à titre d'information et n'ont aucun effet juridique propre.