Aller au contenu principal

Vie privée

Politique de confidentialité

Transparence totale sur la collecte, le traitement et la durée de vie de vos données personnelles.

Dernière mise à jour :

Introduction

RackList est une plateforme indépendante de comparaison d'hébergeurs (VPS, game, dédiés, web). La protection de vos données personnelles est une exigence fondamentale : cette politique décrit quelles données nous collectons, pour quelles finalités, sur quelle base légale, pendant combien de temps et comment vous pouvez exercer vos droits. Aucune donnée n'est revendue, louée ou partagée avec des tiers à des fins commerciales ou publicitaires.

Pour la liste exhaustive des cookies et stockages locaux utilisés par RackList (nom, type, durée, finalité, base de consentement), consultez notre politique cookies dédiée. Le consentement aux cookies non strictement nécessaires (Cloudflare Web Analytics) est recueilli via le bandeau de consentement RackList - acceptation et refus présentés à parité visuelle conformément aux lignes directrices CNIL 2020. Aucun cookie publicitaire.

1.

Responsable du traitement

RackList est éditée par Alexandre ETEOCLE (entrepreneur individuel), agissant en qualité de responsable du traitement au sens de l'article 4.7 du RGPD.

Éditeur
Alexandre ETEOCLE
Entrepreneur individuel
Contact données personnelles
contact@racklist.eu

Compte tenu de la nature des traitements (absence de données sensibles au sens de l'art. 9 RGPD, absence de profilage à grande échelle, absence de suivi comportemental), la désignation d'un DPO n'est pas obligatoire au sens de l'art. 37 RGPD. Les demandes sont traitées directement par l'éditeur sous 30 jours conformément à l'art. 12.3 RGPD.

2.

Données collectées

Compte utilisateur

À l'inscription nous collectons :

  • Adresse e-mail (chiffrée au repos via libsodium, indexée par blind-index déterministe pour l'authentification)
  • Nom d'utilisateur (chiffré au repos, affiché publiquement sur vos reviews)
  • Prénom / nom (chiffrés au repos, optionnels)
  • Mot de passe (haché bcrypt - jamais lisible en clair)
  • Identifiants OAuth (Google, Discord, GitHub, ClientXCMS) si vous choisissez une connexion fédérée
  • Langue préférée et thème clair/sombre

Fiche hébergeur

Si vous revendiquez ou créez une fiche :

  • Informations publiques de l'hébergeur (nom commercial, site, logo)
  • Infrastructure déclarée (datacenters, ASN, types d'hébergement, fournisseurs réseau)
  • Offres commerciales (formules, tarifs, spécifications)
  • Informations légales de l'entreprise (raison sociale, pays, immatriculation - lorsque volontairement renseignées)

Reviews

Votre note, titre, contenu, et identifiant utilisateur. Les reviews sont publiques et associées à votre nom d'utilisateur. Une empreinte navigateur non identifiante et l'adresse IP sont conservées uniquement pour la détection de fraude et l'anti-multi-comptes.

Messagerie interne

Sujet, contenu et participants des conversations entre utilisateurs et hébergeurs. Lisibles uniquement par les participants.

Données techniques

Pour le fonctionnement et la sécurité du service :

  • Adresse IP (session, reviews, détection de fraude)
  • User-Agent navigateur (session, fraude)
  • Identifiant de session (cookie chiffré côté serveur, TTL 24h)
  • Empreinte navigateur non identifiante (uniquement pour les reviews, anti-doublons)

Scopes OAuth demandés par fournisseur

Lorsque vous choisissez une connexion fédérée, RackList demande au fournisseur OAuth uniquement les autorisations strictement nécessaires à la création du compte. Vous pouvez vérifier ce que nous demandons en lisant les contrôleurs de connexion (App\Controller\Security\OAuth\*Controller.php) et en révoquant l'autorisation à tout moment chez le fournisseur.

Fournisseur Scopes demandés Données reçues
Google openid email profile Identifiant Google (sub), adresse e-mail vérifiée, nom d'affichage, photo de profil
Discord identify email Identifiant Discord, nom d'utilisateur (et discriminator legacy), adresse e-mail, avatar
GitHub user:email Identifiant GitHub, login public, profil public, adresse e-mail principale (la première vérifiée si plusieurs)
ClientXCMS (scope par défaut, pas de scope explicite demandé) Identifiant ClientXCMS, e-mail et nom exposés par l'instance OAuth2 configurée via OAUTH_CLIENTXCMS_URL

Ce que nous ne demandons jamais

Aucun scope d'écriture (envoi de mail, publication, gestion de contacts, accès au calendrier, drive, scopes Discord guilds.join, scopes GitHub repo). Si un fournisseur OAuth ajoute un nouveau scope par défaut, nous le documentons ici lors de la mise à jour.

3.

Finalités et bases légales

Chaque traitement repose sur une base légale explicite conformément à l'art. 6 RGPD. Un registre des activités de traitement est tenu conformément à l'art. 30 RGPD et disponible sur demande motivée.

Finalité Base légale Durée de conservation
Gestion du compte et authentification Exécution du contrat (art. 6.1.b) Durée de vie du compte
Publication et affichage des reviews Exécution du contrat (art. 6.1.b) Tant que le compte existe
Conservation des reviews anonymisées après effacement partiel Intérêt légitime (art. 6.1.f) Sans limite de principe, sauf opposition motivée
Détection de fraude, anti-multi-comptes, modération Intérêt légitime (art. 6.1.f) 12 mois après la dernière activité
Messagerie utilisateur ↔ hébergeur Exécution du contrat (art. 6.1.b) Tant que les deux comptes existent
Sécurité, prévention des abus, bannissements Intérêt légitime (art. 6.1.f) 12 mois glissants
Journal d'actions administrateurs (audit) Obligation légale de traçabilité + intérêt légitime 5 ans (PII expurgée lors de la purge du compte)
Envoi de newsletter Consentement (art. 6.1.a) Jusqu'au désabonnement
Focus RGPD
4.

Focus : conservation des reviews anonymisées (ERASE_PRIVATE)

Lorsque vous choisissez l'option « Effacer mes données privées » (ERASE_PRIVATE) depuis votre page de suppression de compte, vos données personnelles (e-mail, nom, mot de passe, OAuth, messages privés, notifications, alertes) sont définitivement effacées. Vos reviews publiques sont en revanche conservées avec une identité anonymisée. Nous détaillons ci-dessous la base légale et l'analyse d'équilibre qui justifient cette conservation.

Base légale : intérêt légitime (art. 6.1.f RGPD)

La conservation des reviews anonymisées repose sur l'intérêt légitime poursuivi par RackList et par la communauté des consommateurs d'hébergement, conformément à l'article 6.1.f du RGPD. Cet intérêt légitime prévaut tant qu'il ne porte pas une atteinte disproportionnée à vos droits et libertés fondamentaux - la coupure du lien entre l'avis et votre identité assurant cette proportionnalité.

Finalité légitime

  • Utilité publique : éclairer les futurs clients sur la qualité et la fiabilité des hébergeurs référencés.
  • Connaissance collective : le retrait d'une review individuelle dégraderait la représentativité des scores agrégés calculés sur plusieurs années d'historique.
  • Liberté d'expression et d'information (art. 11 Charte des droits fondamentaux de l'UE, art. 10 CEDH), dont relèvent les avis consommateurs.
  • Prévention des manipulations : permettre à un auteur de supprimer ses reviews négatives sur simple demande ouvrirait la voie à l'achat-suppression et fausserait la concurrence.

Test de mise en balance (balancing test)

Nous avons évalué l'équilibre entre notre intérêt légitime et vos droits conformément aux lignes directrices de l'EDPB (ex-G29, WP217). Les éléments retenus :

  • Nature des données conservées : exclusivement le contenu rédigé volontairement par vous pour publication, avec un identifiant anonymisé sans lien avec votre identité. Aucune donnée sensible au sens de l'art. 9 RGPD n'est concernée.
  • Attente raisonnable : en publiant un avis public, vous pouviez raisonnablement anticiper qu'il reste consultable dans la durée (principe constant en jurisprudence consommateur - TGI Paris, 11 avril 2013 ; CA Paris 1re ch., 10 mars 2021).
  • Suppression du lien identitaire : nom, e-mail, OAuth, IP et empreinte associés à votre compte sont effacés. La review n'est plus attribuable à une personne identifiable au sens de l'art. 4.1 RGPD.
  • Bénéfice public : les consommateurs tiers et la régulation du marché de l'hébergement tirent une valeur mesurable de la persistance de l'historique d'avis.

Garanties mises en place

  • Vous choisissez librement entre cinq politiques de suppression (désactivation, masquage, anonymisation, effacement partiel, effacement total). Seul l'effacement total supprime les reviews.
  • L'option ERASE_ALL reste toujours disponible et retire définitivement vos reviews si vous estimez votre intérêt supérieur - aucune contrainte tarifaire ni friction technique ne limite ce choix.
  • 30 jours de délai de réflexion permettent de revenir sur n'importe quelle demande d'effacement (voir section dédiée ci-dessous).
  • Aucun identifiant technique résiduel (IP, empreinte, user-agent) ne permet de réassocier une review anonymisée à votre identité post-effacement.
  • Option « mention publique d'effacement » affichant explicitement l'exercice du droit à l'effacement sur les reviews concernées.

Droit d'opposition renforcé (art. 21 RGPD)

Même après avoir choisi ERASE_PRIVATE, vous conservez le droit de vous opposer à la conservation de vos reviews anonymisées en invoquant un motif légitime tenant à votre situation particulière (art. 21.1 RGPD). Envoyez votre demande motivée à contact@racklist.eu : nous basculerons votre dossier vers un ERASE_ALL (suppression complète des reviews + recalcul des scores hébergeurs) sauf à démontrer des motifs impérieux prévalant sur vos intérêts, droits et libertés. En cas de désaccord persistant, vous pouvez saisir la CNIL.

Registre des traitements (art. 30 RGPD)

Ce traitement est inscrit au registre des activités de traitement tenu par le responsable. Contenu du registre pour cette activité : finalité (utilité publique de l'avis hébergeur et intégrité des scores agrégés), catégories de données (contenu + note + identifiant anonymisé), destinataires (public), base légale (intérêt légitime - art. 6.1.f), durée de conservation (sans limite de principe, sauf opposition motivée), mesures de sécurité (suppression du lien identitaire, chiffrement des données restantes au repos). Une copie du registre est communiquée sur demande motivée à contact@racklist.eu.

5.

Délai de réflexion de 30 jours

Lorsque vous demandez une suppression irréversible de votre compte (ANONYMIZE, ERASE_PRIVATE, ERASE_ALL), votre demande n'est pas exécutée immédiatement : elle est enregistrée et un délai de réflexion de 30 jours s'écoule avant toute opération destructive sur vos données.

Nature juridique du délai

Ce délai est un **délai de réflexion (cooling-off period)**, pas un délai de rétention au sens du RGPD. L'article 17 du RGPD impose un effacement « sans retard injustifié » mais n'interdit pas d'aménager un sas d'annulation destiné à protéger l'utilisateur contre une décision impulsive ou un accès frauduleux à son compte. RackList n'est soumis à aucune obligation légale (fiscale, AML, commerciale) qui imposerait de conserver vos données au-delà de votre demande : le délai de 30 jours existe uniquement dans votre intérêt et peut être interrompu à tout moment par vous.

Distinction clé

Délai de rétention = obligation légale imposée au responsable de conserver des données pendant une durée définie (ex. comptabilité : 10 ans, art. L123-22 Code de commerce). Nous n'en avons aucune sur vos données de compte.

Délai de réflexion = fenêtre d'annulation offerte à l'utilisateur, révocable par l'utilisateur lui-même. Pas d'obligation de notre côté, juste une garantie pour vous.

Droit d'annulation

Pendant les 30 jours, vous pouvez annuler votre demande de deux manières équivalentes, sans frais ni justification :

  • En vous reconnectant à votre compte : l'interface vous propose d'annuler en un clic.
  • En activant le lien d'annulation présent dans l'e-mail de confirmation que vous avez reçu lors de la demande.

L'annulation est immédiate et totale : toutes vos données restent intactes, aucune opération irréversible n'a été effectuée. L'annulation est techniquement garantie tant que l'horodatage `deletion_requested_at + 30 jours` n'est pas dépassé.

Passé le délai

À l'expiration des 30 jours, la politique que vous avez choisie est exécutée de manière irréversible par un processus automatique (purge transactionnelle). Vous recevez alors un e-mail confirmant l'exécution. Passé ce point, aucune récupération n'est possible.

Politiques sans délai de réflexion

Les politiques réversibles (DEACTIVATE, HIDE_PROFILE) prennent effet immédiatement et peuvent être annulées à tout moment - sans délai, puisque aucune donnée n'est effacée.

6.

Décisions automatisées et profilage (art. 22 RGPD)

RackList n'applique aucune décision automatisée produisant des effets juridiques ou affectant significativement les utilisateurs au sens de l'art. 22.1 RGPD. Le service de détection de fraude (`FraudDetectionService`) utilise des règles automatiques (empreinte, IP, patterns) pour **signaler** des comportements suspects à un modérateur humain qui prend la décision finale. Les scores d'hébergeurs sont des agrégats statistiques publics, pas une décision individuelle vous concernant. Aucun profilage publicitaire, comportemental ou de notation personnelle n'est effectué.

7.

Analyse d'impact relative à la protection des données (AIPD - art. 35 RGPD)

L'article 35 du RGPD impose une analyse d'impact relative à la protection des données (AIPD, ou DPIA en anglais) lorsqu'un traitement est susceptible d'engendrer un risque élevé pour les droits et libertés des personnes physiques.

Évaluation de l'obligation

Après analyse des critères cumulatifs définis par l'art. 35.3 RGPD et de la liste des traitements soumis à AIPD adoptée par la CNIL (délibération n° 2018-326 du 11 octobre 2018), RackList considère qu'une AIPD formelle n'est **pas obligatoire** à ce stade du service. Les motifs de cette analyse sont documentés ci-dessous conformément au principe d'accountability (art. 5.2 RGPD).

Critères écartés

Aucun des critères habituels déclenchant une AIPD obligatoire n'est rempli :

  • Aucun traitement de données sensibles au sens de l'art. 9 RGPD (santé, opinions religieuses/politiques/syndicales, orientation sexuelle, données biométriques, données génétiques).
  • Absence de traitement à grande échelle : l'effectif d'utilisateurs reste à ce stade bien en-deçà des seuils d'alerte retenus par les lignes directrices WP248 du G29/EDPB.
  • Aucune surveillance systématique à grande échelle d'une zone accessible au public (art. 35.3.c).
  • Aucune décision entièrement automatisée produisant des effets juridiques ou affectant significativement les personnes (art. 35.3.a et art. 22) - voir section dédiée.
  • Aucun traitement ciblant spécifiquement des personnes vulnérables (mineurs, salariés, patients) au-delà de ce qui est strictement nécessaire à l'inscription (cf. section Mineurs).
  • Aucun recours à une technologie innovante présentant des risques nouveaux (reconnaissance faciale, biométrie comportementale, IoT, IA décisionnelle, etc.).
  • Aucun croisement ni combinaison de jeux de données issus de finalités hétérogènes.

Engagement de réévaluation

L'absence d'obligation formelle actuelle ne dispense pas d'anticiper. En conséquence :

  • Une AIPD complète sera conduite et documentée avant tout franchissement des seuils de grande échelle, toute introduction d'un traitement à risque élevé (profilage individuel, scoring de réputation personnelle, biométrie) ou toute évolution fonctionnelle matérialisant un nouveau risque.
  • Chaque évolution substantielle du service fait l'objet d'une analyse préalable de risques et, le cas échéant, d'une mise à jour du registre des traitements (art. 30 RGPD).
  • Les choix de conception à impact vie privée - chiffrement au repos (libsodium), pseudonymisation HMAC des comptes supprimés, délai de réflexion de 30 jours, minimisation des données, finalités explicites, séparation public/privé des artefacts utilisateur - sont documentés dans le code source et dans la présente politique, tenant lieu de mise en œuvre du « privacy by design » au sens de l'art. 25 RGPD.
  • En cas de doute sur le niveau de risque d'un nouveau traitement, une consultation préalable de la CNIL (art. 36 RGPD) sera initiée avant mise en production.

Transparence

La présente décision de ne pas réaliser d'AIPD à ce stade est datée, argumentée et révisable. Une synthèse des analyses de risque menées (actuelles et futures) peut être communiquée sur demande motivée à contact@racklist.eu.

8.

Transferts hors Union Européenne (art. 44-49 RGPD)

Les données applicatives sont hébergées sur des serveurs situés dans l'Espace Économique Européen (Hetzner Online GmbH, Allemagne), le transit IP étant assuré depuis la France par Royale Hosting. Aucun transfert hors EEE n'est effectué par défaut. Si un prestataire ponctuel (provider OAuth, CDN, paiement) implique un transfert, il est encadré par les clauses contractuelles types adoptées par la Commission européenne (décision 2021/914) ou par une décision d'adéquation en vigueur (notamment UE-US Data Privacy Framework, décision 2023/1795). La liste détaillée des sous-traitants ayant accès à une partie des données figure à l'Annexe 3 de l'Accord de traitement des données (DPA) et est communiquée sur demande motivée à contact@racklist.eu.

9.

Mineurs (art. 8 RGPD)

Le service n'est pas destiné aux personnes de moins de 15 ans. L'inscription requiert d'avoir atteint l'âge du consentement numérique fixé à 15 ans en France par la loi n° 2018-493. Si nous constatons qu'un compte a été créé par un mineur de moins de 15 ans sans consentement parental vérifiable, ce compte est supprimé et les données associées effacées.

10.

Violation de données personnelles (art. 33 et 34 RGPD)

En cas de violation susceptible d'engendrer un risque pour vos droits et libertés, nous notifions la CNIL dans les 72 heures suivant la constatation, conformément à l'art. 33 RGPD. Si le risque est élevé, vous êtes informé individuellement dans les meilleurs délais et par un canal distinct (e-mail + bannière in-app), conformément à l'art. 34 RGPD. Le détail de l'incident, les données concernées, les mesures prises et les recommandations vous sont communiqués de manière claire et compréhensible.

11.

Partage des données

Aucune vente, aucune location, aucun partage à des fins publicitaires ou commerciales.

Les seuls destinataires techniques sont :

  • Service d'envoi d'e-mails transactionnels (vérification de compte, réinitialisation, invitations, notifications). Seule l'adresse du destinataire est transmise au prestataire, encadré par un contrat de sous-traitance art. 28 RGPD.
  • Monitoring d'erreurs auto-hébergé sur l'infrastructure du responsable (aucun PII transmis à un service tiers, envoi de PII désactivé côté SDK).
  • Aucun outil d'analyse comportementale, aucune publicité, aucun remarketing : pas de Google Analytics, pas de Facebook Pixel, pas de Mixpanel, aucun cookie de suivi tiers. Une seule mesure d'audience anonyme peut être chargée après votre consentement explicite via le bandeau de consentement : Cloudflare Web Analytics (aucun cookie déposé, aucune IP collectée, aucun profilage individuel ; voir politique cookies).
RGPD art. 14
12.

Données collectées indirectement (art. 14 RGPD)

Certaines données personnelles que nous traitons ne sont pas collectées directement auprès de la personne concernée mais reçues d'un tiers. Conformément à l'article 14 du RGPD, vous trouverez ci-dessous le détail de ces sources, des finalités, des bases légales et des moyens dont vous disposez pour exercer vos droits.

Pourquoi cette section

L'art. 14 RGPD impose au responsable de traitement d'informer toute personne dont les données ont été collectées indirectement. Cette information doit être délivrée dans un délai raisonnable n'excédant pas un mois après l'obtention des données, ou au plus tard lors de la première communication avec la personne concernée. La présente section constitue cette information générale ; une notification individuelle est en outre déclenchée lorsqu'une catégorie particulière de personnes est concernée (cf. tableau ci-dessous).

Sources indirectes utilisées par RackList :

Source Catégories de données reçues Finalité Base légale Conservation Comment vous opposer
Fournisseurs OAuth (Google, Discord, GitHub, ClientXCMS) Identifiant unique du fournisseur, adresse e-mail vérifiée, nom d'affichage public, photo de profil ou avatar (selon le scope demandé - voir section Données collectées) Création et association d'un compte RackList lors d'une connexion fédérée Exécution du contrat (art. 6.1.b RGPD) ; consentement préalable donné chez le fournisseur OAuth lui-même Tant que la liaison OAuth est active. Suppression immédiate via /account (rubrique « Comptes liés »). Dissocier le compte OAuth depuis /account ; révoquer l'autorisation directement chez le fournisseur (Google : myaccount.google.com/permissions, Discord : Authorized Apps, GitHub : Settings/Applications).
API recherche-entreprises (annuaire-entreprises.data.gouv.fr / Sirene INSEE / RCS BODACC) Raison sociale, SIREN/SIRET, code NAF, adresse du siège, catégorie d'entreprise, nom et année de naissance des dirigeants personnes physiques Pré-remplissage et vérification des fiches d'hébergeurs publiées sur RackList. Les noms de dirigeants ne sont accessibles qu'aux administrateurs lors de la modération et ne sont jamais affichés publiquement. Intérêt légitime (art. 6.1.f RGPD) - publication d'un annuaire d'hébergeurs B2B reposant sur des données publiques diffusées sous licence Etalab Open Licence 2.0 Cache 24 heures côté RackList. Données restituées uniquement tant que l'hébergeur est référencé. Toute personne dont le nom apparaît dans une fiche peut s'opposer (art. 21 RGPD) en écrivant à contact@racklist.eu : nous masquons les données nominatives sur la fiche dans les meilleurs délais, sauf à démontrer un motif légitime impérieux (registre tenu sous l'identifiant LIA-RACKLIST-001).
Formulaire d'invitation hébergeur (referral) Adresse e-mail générique au format info@<domaine-de-l-hebergeur>, nom commercial de l'hébergeur, motif d'invitation Envoyer une invitation unique au mainteneur d'un hébergeur référencé pour lui proposer de revendiquer sa fiche. Aucune relance automatique. Intérêt légitime (art. 6.1.f RGPD) - mise en relation B2B avec mention d'opposition explicite L'adresse e-mail destinataire est conservée 90 jours à des fins anti-spam puis purgée. Aucun re-contact automatique. Chaque invitation contient un lien d'opposition à un clic vers /referral/optout/<token> (cf. F-CONS-06). L'opposition est définitive et bloque toute future invitation pour ce domaine.

Vos droits sur ces données indirectes

Les droits décrits dans la section « Vos droits » s'appliquent intégralement aux données collectées indirectement. Vous pouvez exercer un droit d'accès, de rectification, d'effacement, d'opposition ou de limitation auprès de contact@racklist.eu. Si vous découvrez l'existence d'un traitement vous concernant à l'occasion de la lecture de cette politique, le délai de réponse RGPD (30 jours, art. 12.3) court à compter de votre demande.

13.

Durées de conservation

  • Données de compte : conservées tant que le compte est actif. Effacement définitif 30 jours après votre demande (délai de réflexion, annulable).
  • Reviews : tant que le compte existe.
  • Reviews anonymisées (après ERASE_PRIVATE ou ANONYMIZE) : sans limite de principe, sauf opposition motivée (voir section intérêt légitime).
  • Messages privés : tant que les deux participants ont un compte actif.
  • Sessions : 24 heures après la dernière activité.
  • Logs d'actions administrateurs : 5 ans, avec purge automatique des PII lors de la suppression du compte concerné.
  • Données anti-fraude (IP, empreinte) : 12 mois glissants.
14.

Vos droits

Conformément au RGPD (art. 15 à 22), vous disposez des droits suivants sur vos données personnelles :

  • Droit d'accès (art. 15) : obtenir une copie de toutes les données que nous détenons à votre sujet.
  • Droit de rectification (art. 16) : corriger les informations inexactes via /account/profile/edit (e-mail, nom d'utilisateur, prénom, nom). Toute modification d'e-mail déclenche une nouvelle vérification.
  • Droit à l'effacement (art. 17) : cinq politiques granulaires disponibles depuis votre page /account/delete, dont l'effacement complet (ERASE_ALL).
  • Droit à la portabilité (art. 20) : export JSON structuré de vos données via /account/export.
  • Droit d'opposition (art. 21) : notamment contre les traitements fondés sur l'intérêt légitime (ex. conservation des reviews anonymisées), en invoquant un motif légitime tenant à votre situation particulière.
  • Droit à la limitation (art. 18) : geler temporairement un traitement contesté le temps de l'instruction.
  • Retrait du consentement (art. 7.3) : à tout moment pour les traitements fondés sur le consentement (newsletter notamment), aussi simplement que vous l'avez donné.
  • Droit de ne pas faire l'objet d'une décision automatisée (art. 22) - non applicable chez RackList : aucune décision automatisée n'est appliquée.

Portée des droits

Ces droits portent sur vos données personnelles (compte, e-mail, messages, reviews). Les fiches hébergeurs constituent un contenu éditorial d'intérêt public et ne relèvent pas du droit à l'effacement personnel. Conformément à la LCEN (art. 6) et au règlement européen DSA (UE 2022/2065, art. 6 et 8), RackList n'a pas d'obligation générale de surveillance et ne retire un contenu que sur décision judiciaire ou en cas de contenu manifestement illicite dûment notifié.

Comment exercer vos droits

Réponse immédiate via /account/export pour le droit d'accès et de portabilité (art. 15 et 20). Pour les autres demandes (rectification, effacement, opposition, limitation, décision automatisée), écrivez à contact@racklist.eu en précisant votre demande et en joignant une preuve d'identité (e-mail de votre compte). Nous répondons sous 30 jours conformément à l'art. 12.3 RGPD, ce délai pouvant être prolongé de deux mois en cas de complexité. En cas de réponse insatisfaisante, vous pouvez introduire une réclamation auprès de la CNIL (cnil.fr, 3 place de Fontenoy - TSA 80715 - 75334 PARIS CEDEX 07) ou de l'autorité de contrôle de votre État membre.

15.

Sécurité

Mesures techniques et organisationnelles mises en œuvre : chiffrement au repos des données personnelles (libsodium) avec blind-index déterministe pour l'authentification, hachage bcrypt des mots de passe, connexions HTTPS uniquement (TLS 1.3), protection CSRF double-submit, throttling de connexion (5 tentatives/minute), sessions sécurisées avec expiration automatique, journalisation des accès administrateurs, chiffrement des sauvegardes, principe du moindre privilège sur les accès serveurs, revues de dépendances et audit de sécurité régulier (composer audit + PHPStan niveau 8).

16.

Sauvegardes (règle 3-2-1)

RackList applique strictement la règle 3-2-1 sur l'ensemble des sauvegardes PostgreSQL, garantissant à la fois la résilience opérationnelle (PRA) et la conformité à l'obligation de sécurité (art. 32 RGPD).

Règle 3-2-1 en pratique

3 copies complètes

Une copie active en production + deux sauvegardes distinctes générées automatiquement (dump logique + réplication physique).

2 supports de stockage différents

Stockage primaire sur le cluster applicatif (SSD NVMe) et stockage secondaire sur baie de sauvegarde indépendante (différente pile logicielle, différent vendeur, différent format).

1 copie hors-site

Au moins une copie géographiquement distante, stockée chez un hébergeur européen tiers, isolée du réseau de production (pull-based, aucun credential de prod vers le site de backup).

Chiffrement des sauvegardes

Toutes les sauvegardes sont chiffrées au repos via AES-256-GCM avec une clé distincte de celle utilisée pour le chiffrement applicatif (libsodium). Les clés de chiffrement backup sont stockées dans un gestionnaire de secrets hors-bande et soumises à rotation annuelle. Les sauvegardes hors-site sont en outre chiffrées en transit (TLS 1.3) et au repos (chiffrement natif du stockage distant).

Durée de conservation des sauvegardes

  • Sauvegardes quotidiennes : 30 jours glissants.
  • Sauvegardes hebdomadaires : 12 semaines.
  • Sauvegardes mensuelles : 12 mois.
  • Au-delà, rotation automatique : chaque sauvegarde expirée est détruite par suppression cryptographique (destruction de la clé) + écrasement du stockage.

Limite technique : purge sélective impossible sur les dumps

**Information importante pour la transparence RGPD :** PostgreSQL produit des sauvegardes sous forme de dumps binaires ou de flux WAL. Une purge sélective ciblant les données d'un utilisateur donné dans un dump chiffré est techniquement impossible sans reconstruire l'intégralité du dump - opération non réalisable à l'échelle sans compromettre l'intégrité de la chaîne de sauvegarde. Cette contrainte est partagée par l'ensemble des systèmes de sauvegarde base de données à l'état de l'art.

Mesures compensatoires

  • Durée de rétention des sauvegardes strictement bornée (maximum 12 mois) et documentée.
  • Chiffrement fort au repos et en transit : même en cas d'accès illégitime à un dump, les données restent inintelligibles.
  • Accès aux sauvegardes restreint à l'administrateur technique, journalisé, soumis à authentification multi-facteurs.
  • Aucune restauration à des fins autres que reprise d'activité : les dumps ne sont jamais utilisés pour lire ou exporter des données d'un utilisateur spécifique.
  • Au terme de la rétention, les clés de chiffrement sont détruites (crypto-shredding) rendant les données irrécupérables même en cas de persistance résiduelle du support.

Cette conception est conforme à la doctrine de la CNIL et du CEPD (EDPB Guidelines 5/2020, §38) qui admet qu'une demande d'effacement puisse être mise en attente le temps que les sauvegardes soient naturellement renouvelées, à condition que : (1) la durée de rétention soit limitée et documentée, (2) aucune réutilisation des sauvegardes en dehors du PRA ne soit effectuée, (3) l'utilisateur en soit informé. Cette section vous en informe.

Tests de restauration

Tests de restauration automatisés mensuels sur un environnement isolé - vérification de l'intégrité des dumps, du chiffrement, du volume et de la cohérence relationnelle. Tout échec déclenche une alerte et un retest manuel.

17.

Image de profil issue d'un fournisseur OAuth

Lorsque vous créez votre compte via Google, GitHub ou Discord, le fournisseur d'identité nous transmet, parmi les données du profil public, une URL pointant vers votre image de profil hébergée chez lui. Cette section décrit précisément comment cette URL est traitée.

Ce que nous stockons

Seule l'URL publique de l'image est enregistrée dans la base de données RackList, sous forme d'une chaîne de texte attachée à votre compte. Nous ne téléchargeons pas l'image, nous ne la copions pas sur nos serveurs et nous ne créons aucune copie locale. L'image elle-même reste hébergée chez le fournisseur d'origine.

Comment l'image s'affiche

Quand une page de RackList doit afficher votre photo (votre profil, vos avis, l'en-tête de votre compte), votre navigateur lit l'URL transmise dans le code HTML et va chercher l'image directement chez le fournisseur. RackList ne sert pas l'image, ne la met pas en cache et ne joue pas le rôle d'intermédiaire technique pour ce contenu.

Conséquence concrète chez chaque fournisseur

  • Google (lh3.googleusercontent.com) : Google reçoit une requête HTTP de votre navigateur à chaque affichage de votre photo sur RackList. Cette requête contient votre adresse IP et l'indication que vous étiez sur racklist.eu au moment de la requête.
  • GitHub (avatars.githubusercontent.com) : même principe, GitHub voit une requête par affichage avec votre adresse IP et la page racklist.eu d'origine.
  • Discord (cdn.discordapp.com) : même principe, Discord voit une requête par affichage avec votre adresse IP et la page racklist.eu d'origine.

Comment contrôler ce comportement

Vous pouvez à tout moment supprimer cette image de votre compte RackList en utilisant la page Modifier mon profil, ou en supprimant votre compte. Une fois l'URL retirée, votre navigateur n'enverra plus de requête au fournisseur. Vous pouvez également contrôler la photo affichée en la modifiant directement chez le fournisseur (Google, GitHub, Discord) : à votre prochaine connexion sur RackList, la nouvelle valeur sera enregistrée.

18.

Modifications de cette politique

Nous pouvons être amenés à mettre à jour cette politique. En cas de modification substantielle (nouvelle finalité, nouveau destinataire, modification de base légale), vous êtes informé par e-mail au moins 30 jours avant la prise d'effet. La date de dernière mise à jour est indiquée en haut de cette page. L'historique des versions est conservé et communiqué sur demande.