Politique de confidentialité
Dernière mise à jour : 27 mai 2026
Cette version est une traduction. La version anglaise (
privacy.en.md) est la version contrôlante. Cette version française est mise à disposition pour la lecture des utilisateurs francophones. En cas de divergence entre les versions linguistiques, la version anglaise prévaut — sauf pour les questions relevant exclusivement du droit allemand des télémédias, du droit allemand de la consommation ou du droit allemand des contrats, pour lesquelles la formulation allemande fait foi.
1. Introduction
Le présent avis décrit la manière dont Uptimia (« nous », « notre »), exploité par JJ Online GmbH, traite vos données à caractère personnel dans le cadre de https://uptimia.com (le « Site ») et du service de monitoring Uptimia (le « Service »), conformément aux articles 13 et 14 du RGPD et au droit équivalent en matière de protection des données. Il vous est fourni à titre d'information ; lorsque le traitement est conditionné à votre consentement, ce consentement est recueilli séparément. Pour les conditions qui régissent votre relation contractuelle avec nous, voir nos Conditions générales d'utilisation.
Collecte directe et indirecte (Art. 13 et Art. 14 RGPD). La plupart des données à caractère personnel décrites au § 3 nous sont fournies directement par vous lorsque vous créez un compte, configurez des moniteurs ou utilisez d'une autre manière le Service. Lorsqu'un élément est plutôt collecté auprès d'un tiers — en particulier :
- les métadonnées de moyen de paiement retournées par Stripe ou PayPal en lien avec votre abonnement ;
- les charges utiles Instant Payment Notification (IPN) de PayPal reçues de PayPal en lien avec chaque transaction, lesquelles peuvent comprendre des champs de contexte transactionnel (devise de règlement, statut du payeur, statut de confirmation d'adresse) qui n'ont pas initialement été fournis par vous ;
- les attributs d'identité retournés par Google ou GitHub via la page de connexion hébergée par Auth0 lorsque vous choisissez de vous connecter par l'intermédiaire d'une connexion sociale (et les jetons associés émis par Auth0) ;
- la normalisation d'adresse, les sorties de validation du numéro de TVA et autres métadonnées de génération de facture retournées par easybill en lien avec l'émission de votre facture (lorsque easybill retourne un champ — telle qu'une adresse postale normalisée ou un drapeau de validité d'un numéro de TVA issu du système VIES de l'UE interrogé via easybill — qui n'a pas été littéralement saisi par vous, ce champ est collecté indirectement) ;
— le tiers qui est la source de ces données est identifié dans l'entrée correspondante du § 5 (Services tiers) ci-dessous, en exécution de notre obligation au titre de l'Art. 14 (2)(f) RGPD de nommer la source. En dehors de ces flux spécifiques, aucune donnée à caractère personnel que nous détenons à votre sujet en qualité de titulaire de compte n'est obtenue auprès d'un tiers.
2. Responsable du traitement
Aux fins du RGPD (Art. 4 (7)) et du droit équivalent en matière de protection des données, le responsable du traitement de vos données à caractère personnel en votre qualité de titulaire d'un compte Uptimia est :
JJ Online GmbH (exploitant Uptimia)
Schönhauser Allee 163, 10435 Berlin
Allemagne
Immatriculée auprès de : Amtsgericht Charlottenburg, HRB 235074 B
USt-IdNr. : DE351060880
Représentée par : Andrius Gecius, Geschäftsführer (gérant)
Téléphone : +49 151 12032902
Courriel — général / Mentions légales : admin@uptimia.com
Courriel — confidentialité et demandes des personnes concernées : privacy@uptimia.com
L'identification complète du prestataire requise par le § 5 DDG figure dans nos Mentions légales (anglais) / Impressum (allemand).
Note sur les rôles. Lorsque vous utilisez Uptimia pour surveiller des ressources que vous exploitez, vous agissez en qualité de responsable du traitement à l'égard des données à caractère personnel que votre monitoring touche — adresses IP de visiteurs captées par les scripts RUM que vous déployez, données d'utilisateurs finaux captées dans les captures d'écran de monitoring transactionnel, charges utiles de réponses de contrôles authentifiés qui comprennent des informations sur l'utilisateur. Dans ce scénario, Uptimia agit en qualité de sous-traitant pour votre compte, dans les conditions de notre DPA — voir § 7 ci-dessous.
La présente Politique décrit notre traitement en qualité de responsable de vos propres données en tant qu'utilisateur du Service. La relation de sous-traitance est décrite au § 7 et dans le DPA.
3. Informations que nous collectons
Nous collectons les catégories suivantes de données à caractère personnel concernant les utilisateurs du Service.
Données du compte
- Identité : adresse électronique, mot de passe (stocké sous forme de hachage bcrypt ; les hachages hérités sont mis à niveau lors de la première connexion réussie), nom complet, jeton opaque de reprise de compte
- Adresse postale : rue, code postal, ville, État, pays, fuseau horaire
- Identification professionnelle : raison sociale, numéro d'identification TVA, monnaie, région de facturation (code ISO à deux caractères)
- Contact : numéro de téléphone, courriel de reporting, libellé d'expéditeur personnalisé pour les envois sortants
- Métadonnées réseau : l'adresse IP depuis laquelle vous vous êtes inscrit et l'adresse IP depuis laquelle vous vous êtes connecté le plus récemment
- Dates de cycle de vie : date d'inscription, date de dernière activité, date de début de l'abonnement, date de renouvellement de l'adhésion, date de renouvellement des crédits SMS
- Sécurité : état d'authentification à deux facteurs, préférence de notification par courriel des connexions, horodatage de la dernière tentative de connexion en échec, compteur de tentatives échouées, score de risque heuristique interne (indicatif ; voir § 8 et la note de conservation au § 11)
- Préférences opérationnelles : vos états d'opt-in aux alertes par courriel et par SMS, état de désabonnement, drapeaux d'accueil, jours « ne pas alerter », votre fenêtre d'heures d'alerte
- Marketing / cycle de vie : le code UTM ou code de source de référence figurant dans l'URL par laquelle vous nous avez atteint pour la première fois
Données de facturation
- Métadonnées de facture, montants, références et références aux PDF stockés
- Métadonnées de moyen de paiement (jetons Stripe / PayPal / carte bancaire — nous ne voyons jamais le numéro de carte complet)
- Lorsque vous payez via PayPal, la charge utile Instant Payment Notification de PayPal reçue de PayPal en lien avec la transaction
Données d'authentification et de session
- Cookies de session listés dans notre Politique relative aux cookies § 4
- Enregistrements d'audit des connexions à deux facteurs — utilisateur, horodatage, adresse IP, user-agent — écrits chaque fois que vous validez un défi 2FA
- Enregistrements de demandes de réinitialisation de mot de passe — générés à la demande lorsque vous demandez une réinitialisation
- Clés API personnelles que vous créez pour un accès programmatique au Service — stockées sous forme de hachages unidirectionnels uniquement ; voir § 12
- Compteur de tentatives de connexion échouées et horodatage du dernier échec dans votre enregistrement utilisateur
Canaux d'authentification à deux facteurs. Lorsque vous activez l'authentification à deux facteurs, le code à usage unique est délivré soit par courriel (via notre sous-traitant de messagerie transactionnelle — AWS SES, voir § 5.2), soit généré localement par une application d'authentification TOTP sur votre appareil (Google Authenticator, 1Password, Authy ou équivalent). Nous n'envoyons pas de codes 2FA par SMS et ne transmettons votre numéro de téléphone à aucun prestataire SMS dans le flux 2FA. Lorsque la fonctionnalité d'alerte par SMS est activée séparément par vous pour les alertes de monitoring, ce flux est documenté aux § 5 et § 7 (Twilio).
Configurations de moniteurs que vous créez
Lorsque vous créez un moniteur, la configuration est stockée dans notre base de données d'application et transmise au réseau de sondes au moment de l'exécution. Les configurations peuvent contenir des données à caractère personnel :
- Contrôles HTTP authentifiés : l'URL, les identifiants d'authentification HTTP (identifiants Basic et/ou en-têtes de requête personnalisés, qui peuvent transporter des jetons bearer ou des clés API), tout corps POST que vous fournissez et les motifs de contenu attendu que vous configurez
- Moniteurs transactionnels : les sélecteurs CSS et les expressions XPath utilisés pour piloter le parcours, ainsi que toute valeur littérale (y compris les identifiants de test) que le parcours soumet à chaque étape
Les identifiants et secrets que vous fournissez dans les configurations de moniteurs sont conservés sous chiffrement enveloppe au niveau colonne avec des clés gérées séparément, comme décrit au § 12.
Résultats de contrôles
Générés par notre réseau de sondes à chaque contrôle :
- Uptime / HTTP : temps par phase, statut, type d'erreur et le corps de réponse retourné par l'URL surveillée (les corps de réponse sont conservés 7 jours puis expirent automatiquement, conformément au § 11)
- SSL : émetteur du certificat, dates de validité et toute erreur liée au certificat observée
- Domaine / WHOIS : registrar, serveurs de noms, dates de cycle de vie et réponse WHOIS complète
- Speed : temps de chargement, ventilation par ressource, scores PageSpeed
- Transaction : statut, durée par étape et une capture d'écran stockée de la page à chaque étape (la capture d'écran peut contenir des données à caractère personnel visibles à l'écran au moment de la capture)
- Real User Monitoring (RUM) : mesures agrégées uniquement — temps de chargement de page, vues de pages, comptes d'erreurs JavaScript, origine géographique, classe de navigateur et d'appareil. Aucune mesure Core Web Vitals (LCP / INP / CLS / TTFB) n'est collectée (selon le périmètre produit)
- Virus / malware : le statut retourné par le prestataire de filtrage anti-malware ; aucune charge utile analysée n'est conservée
- Agent serveur : mesures CPU, mémoire, disque et réseau diffusées par l'agent que vous déployez sur vos propres serveurs. Ces mesures décrivent l'état de santé d'un serveur, non d'une personne physique. Elles sont toutefois rattachables à vous en tant que titulaire de compte parce que l'agent est enregistré sur votre compte Uptimia ; sur ce rattachement, nous les traitons comme des données à caractère personnel vous concernant en tant que titulaire de compte pour la durée de la relation contractuelle — traitées sur le fondement de l'Art. 6 (1)(b) RGPD (contrat). L'agent ne transmet aucun identifiant d'utilisateur final depuis le serveur surveillé (pas de listes de processus, pas de noms de comptes utilisateurs, pas de variables d'environnement) ; les catégories listées ci-dessus sont exhaustives.
Les durées de conservation pour chacune des catégories ci-dessus sont régies par le § 11.
Configurations des canaux de notification
Lorsque vous configurez un canal d'alerte (Slack, Discord, Twilio SMS, Meta WhatsApp Cloud, PagerDuty, Atlassian Statuspage, Microsoft Teams, Mattermost, Telegram, X, webhooks génériques), nous stockons les identifiants du canal et les enregistrements de contact que vous fournissez. Chacun est transmis au canal choisi à chaque alerte.
Double rôle des canaux d'alerte. Les canaux d'alerte transportent deux catégories différentes de données sous deux qualifications de rôle différentes, et le même tiers (Slack, Twilio, etc.) porte les deux casquettes :
- Enregistrements de contacts et identifiants de l'équipe ops — les numéros de téléphone, identifiants de workspace et de canal Slack, clés d'intégration PagerDuty, jetons de bot Telegram, URL de webhooks, etc. que vous fournissez, ainsi que la charge utile d'alerte elle-même lorsqu'elle est adressée à votre propre équipe ops. Ces enregistrements identifient votre personnel (vos ingénieurs d'astreinte, votre personnel de réponse aux incidents), non les visiteurs de vos sites surveillés. Pour ce volet, Uptimia est responsable du traitement à l'égard du flux de données du canal d'alerte, et les tiers du canal d'alerte sont les propres prestataires de service d'Uptimia ; la base juridique est l'Art. 6 (1)(b) RGPD (exécution de votre contrat d'abonnement — la livraison de l'alerte est la prestation contractée) et l'Art. 6 (1)(f) RGPD (intérêt légitime de vous, titulaire du compte, à être notifié). Ces flux sont inventoriés au § 5 dans le cadre de la pile de relations en qualité de responsable d'Uptimia.
- Données d'utilisateur final / visiteur pouvant apparaître incidemment dans une charge utile d'alerte — par ex. lorsque vous avez rédigé une étape de monitoring transactionnel dont le message d'échec contient un identifiant d'utilisateur final, ou lorsqu'un extrait de corps de réponse de contrôle authentifié fait apparaître des données à caractère personnel d'un de vos visiteurs et est inclus dans le résumé d'alerte. Pour ce composant incidentel, Uptimia agit en qualité de sous-traitant pour votre compte (en tant que Responsable du traitement), le tiers du canal d'alerte devient un Sous-traitant ultérieur pour ce volet, et le flux relève de l'inventaire des sous-traitants ultérieurs de l'Annexe C.5 du DPA. Ce composant est celui que vise le § 7 ci-dessous.
Les deux qualifications coexistent parce que l'événement d'alerte est un seul message portant les deux types de contenu. L'analyse de la relation en qualité de responsable au § 5 régit le volet enregistrements-de-contacts-et-identifiants et le volet alerte-adressée-à-votre-équipe-ops ; l'analyse du rôle de sous-traitant au § 7 régit uniquement le volet données-visiteurs-incorporées.
Données de support
Lorsque vous nous contactez, nous recevons et stockons le contenu de l'interaction ainsi que les identifiants de contact que vous fournissez :
- Conversations du widget de chat HelpCanvas — le widget de chat est chargé sur le site marketing (https://uptimia.com) et, lorsque vous êtes connecté, dans la surface applicative. Chaque conversation est stockée comme le fil de messages lui-même, votre nom d'affichage et votre adresse électronique (lorsque vous les fournissez) et les métadonnées techniques que HelpCanvas enregistre sur la session (horodatages, User-Agent du navigateur, adresse IP, URL de la page sur laquelle la conversation a été démarrée). HelpCanvas est un produit JJ Online tournant sur l'infrastructure UE propre de JJ Online (voir § 5.7 ci-dessous) ; la conversation ne sort pas de l'UE et n'est partagée avec aucun tiers qui ne soit déjà un sous-traitant ultérieur pour HelpCanvas.
- Correspondance par courriel adressée à nos adresses de rôle —
admin@uptimia.com(général),privacy@uptimia.com(confidentialité et demandes des personnes concernées) et toute autre adresse de rôle à laquelle vous écrivez. Nous recevons et stockons les en-têtes du courriel (votre adresse d'expéditeur, notre adresse de destinataire, horodatages, message-id), le corps du message et toute pièce jointe que vous choisissez d'envoyer. Le courrier entrant et sortant est traité via AWS SESeu-central-1(voir § 5.2) et stocké sur l'infrastructure de messagerie UE propre de JJ Online.
Catégories. Identifiants (nom, adresse électronique), contenu en texte libre (votre message et toute pièce jointe) et métadonnées techniques (horodatages, IP, User-Agent, contexte de page pour le widget de chat ; en-têtes SMTP pour le courriel).
Base juridique. Art. 6 (1)(b) RGPD lorsque la correspondance porte sur l'exécution du contrat de Service que vous avez avec nous (par ex. une question fonctionnelle sur un compte payant) ; Art. 6 (1)(c) RGPD lorsque la correspondance est elle-même l'exécution d'une obligation légale (par ex. la réponse à une demande Art. 12-22 RGPD d'une personne concernée) ; Art. 6 (1)(f) RGPD pour les demandes entrantes de prospects et autres correspondants avec lesquels nous n'avons pas de contrat, l'intérêt légitime étant de répondre aux communications entrantes adressées à nos adresses de rôle publiées.
Destinataires. Internes : membres de JJ Online GmbH qui gèrent la file de support, de facturation ou de confidentialité concernée. Sous-traitants ultérieurs externes : AWS SES eu-central-1 pour le transport courriel (§ 5.2) ; la pile applicative HelpCanvas tourne sur l'infrastructure UE propre de JJ Online et n'introduit pas de destinataire tiers (§ 5.7 et § 11 « Conversations de support hébergées par HelpCanvas »). Aucun contenu de support n'est partagé avec des tiers au-delà de ce qui est nécessaire pour acheminer le courriel ou pour traiter votre demande spécifique (par exemple, lorsque vous nous demandez de transmettre une question de facturation à Stripe, nous le ferons sur votre instruction).
Conservation. Durée du dossier de support plus 3 années civiles ancrées à la fin d'année, conformément à la ligne Correspondance de support du § 11, sur le fondement de l'Art. 6 (1)(f) RGPD lu en combinaison avec la regelmäßige Verjährungsfrist des §§ 195 + 199 BGB. La conversation sur la plateforme HelpCanvas et la correspondance par courriel sont soumises à la même conservation ; voir § 11 « Conversations de support hébergées par HelpCanvas » pour l'analyse de la plateforme-source.
Métadonnées de requête côté serveur lues à chaque requête
- Votre adresse IP (utilisée pour la limitation de débit et la défense contre les abus)
- La chaîne User-Agent de votre navigateur (utilisée pour la validation d'intégrité de session ; hachée dans le contrôle d'intégrité de session)
L'adresse IP n'est conservée dans votre enregistrement de compte que sous forme des valeurs d'inscription et de connexion la plus récente décrites sous « Données du compte » ci-dessus ; elle est par ailleurs lue de manière transitoire et non conservée. La chaîne User-Agent n'est pas conservée au-delà du contrôle d'intégrité de session haché.
Caractère obligatoire de la fourniture de ces informations (Art. 13 (2)(e) RGPD)
Nous sommes tenus, en vertu de l'Art. 13 (2)(e) RGPD, de vous informer du caractère statutaire ou contractuel de la fourniture de vos données à caractère personnel et des conséquences en cas de non-fourniture :
- Requis par la loi. Votre nom, votre adresse de facturation, votre numéro de TVA le cas échéant et les détails de transaction doivent être conservés pour respecter les obligations fiscales et comptables allemandes (§ 147 AO, § 257 HGB ; § 14 UStG pour le contenu des factures TVA). Sans ces éléments, nous ne pouvons pas vous facturer légalement.
- Requis par le contrat. Votre adresse électronique, votre mot de passe, votre identifiant de moyen de paiement de facturation et les configurations de moniteurs que vous soumettez sont nécessaires à l'exploitation du contrat de Service en vertu de l'Art. 6 (1)(b) RGPD. Sans eux, nous ne pouvons pas fournir le Service.
- Requis pour l'accès au compte et la sécurité. Votre adresse IP, votre user-agent, les horodatages de connexion et l'état 2FA sont traités en vertu de l'Art. 6 (1)(f) RGPD pour assurer la sécurité de votre compte.
- Volontaire. Les préférences d'opt-in marketing, les champs de profil optionnels et les retours sont à votre discrétion ; la non-fourniture n'affecte pas votre accès au Service.
Catégories particulières de données à caractère personnel (Art. 9 RGPD)
Nous ne traitons pas sciemment de catégories particulières de données à caractère personnel au sens de l'Art. 9 (1) RGPD — c'est-à-dire des données révélant l'origine raciale ou ethnique, les opinions politiques, les convictions religieuses ou philosophiques, l'appartenance syndicale, des données génétiques, des données biométriques aux fins d'identifier une personne physique de manière unique, des données concernant la santé ou des données concernant la vie sexuelle ou l'orientation sexuelle d'une personne physique. Uptimia est un produit d'observabilité B2B ; aucune des catégories listées au § 3 ci-dessus (compte, facturation, authentification, configurations de moniteurs, résultats de contrôles, configurations de canaux de notification, données de support, métadonnées de requête côté serveur) n'est conçue ou destinée à capter des données Art. 9.
Veuillez ne pas nous soumettre de données de catégorie particulière — par exemple, n'en collez pas dans les URL de moniteurs, les en-têtes de moniteurs, les corps de requête, les messages de test de canal d'alerte ou les tickets de support, et ne scriptez pas de parcours de monitoring transactionnel qui acheminent des données de catégorie particulière à travers Uptimia. Si vous nous soumettez néanmoins de telles données par inadvertance — par exemple dans une description de support en texte libre — nous les traitons comme une réception involontaire : nous ne revendiquons aucune base au titre de l'Art. 9 (2) RGPD pour les traiter comme des données de catégorie particulière, nous ne les utilisons à aucune fin au-delà de ce qui est strictement inévitable pour traiter le ticket de support qui nous les a fait parvenir, et nous supprimerons le champ litigieux sur demande sans préjudice du reste du fil de support. Dans la mesure limitée où la manipulation du champ est inévitable entre la réception et la suppression (par ex., l'agent lit le message afin de comprendre la demande avant de le caviarder), nous nous appuyons sur l'Art. 9 (2)(f) RGPD (traitement nécessaire à la constatation, à l'exercice ou à la défense de droits en justice — ici, le traitement du ticket de support qui repose lui-même sur l'Art. 6 (1)(f) et §§ 195 + 199 BGB tels que présentés au § 11 « Correspondance de support ») uniquement dans la mesure où ce membre est effectivement engagé. Nous ne nous appuyons pas sur l'Art. 9 (2)(e) RGPD (données manifestement rendues publiques par la personne concernée) : la soumission d'informations personnelles dans un ticket de support privé n'est pas une divulgation délibérée, adressée au public, au sens de la lecture étroite de l'Art. 9 (2)(e) requise par Lindqvist (CJUE C-101/01) et les lignes directrices du CEPD, et nous ne la traitons pas comme telle.
Lorsque vous, en qualité de Responsable du traitement, déployez notre script RUM ou un monitoring transactionnel sur une surface qui traite des données de catégorie particulière de vos visiteurs / utilisateurs finaux, il s'agit de votre propre décision de responsable et de votre propre responsabilité au titre de l'Art. 9 RGPD ; rien dans notre Service ou notre DPA ne vous autorise à acheminer des données de catégorie particulière à travers Uptimia, et la déclaration de catégorie de données à l'Annexe A du DPA suppose des données ordinaires de visiteurs / utilisateurs finaux uniquement.
4. Comment nous utilisons vos informations
Nous utilisons les données que nous collectons aux fins exposées ci-dessous. Conformément à l'Art. 13 (1)(c) RGPD, la base juridique est indiquée à côté de chaque finalité.
| Finalité | Base juridique (Art. 6 RGPD) |
|---|---|
| Exploiter, maintenir et améliorer le Service et le Site | Art. 6 (1)(f) — intérêt légitime |
| Vous authentifier, maintenir votre session, faire respecter la 2FA lorsque vous l'avez activée | Art. 6 (1)(b) — contrat |
| Exécuter les configurations de moniteurs que vous créez et délivrer les résultats de contrôles à votre tableau de bord | Art. 6 (1)(b) — contrat |
| Délivrer les alertes aux canaux que vous avez configurés (SMS, WhatsApp, Slack, Discord, Teams, Mattermost, Telegram, PagerDuty, Atlassian Statuspage, X, webhooks) | Art. 6 (1)(b) — contrat |
| Traiter les paiements d'abonnement et émettre les factures | Art. 6 (1)(b) — contrat |
| Tenir les registres fiscaux et comptables | Art. 6 (1)(c) — obligation légale (§ 147 AO, § 257 HGB) |
| Détecter, prévenir et traiter la fraude, les attaques d'identifiants par force brute et les abus du Service | Art. 6 (1)(f) — intérêt légitime à l'intégrité du compte |
| Exécuter vos moniteurs contre les ressources que vous configurez, depuis le réseau de sondes multi-régions | Art. 6 (1)(b) — contrat |
| Mesure de qualité inter-clients et opérations du réseau de sondes — agrégation des résultats des sondes entre les clients pour détecter les anomalies côté sonde, calibrer les chronométrages et identifier les incidents régionaux qui affectent plusieurs clients ; la sortie est agrégée et ne produit aucun signal au niveau individuel | Art. 6 (1)(f) — intérêt légitime à la qualité du service, à la détection d'anomalies de sondes et à la fiabilité de l'ensemble de la plateforme. Nous n'affirmons pas que la sortie agrégée est « anonyme » au sens du cadre strict des trois tests de l'Avis 05/2014 sur les techniques d'anonymisation (ancien) Groupe de l'Article 29 (singularisation, corrélation, inférence, tous défaits) ; nous traitons l'agrégation inter-clients comme pseudonyme pour l'analyse de la base juridique et nous l'ancrons dans l'Art. 6 (1)(f) en conséquence. Les rapports de sortie ne sont publiés qu'à un seuil d'agrégation par région suffisant pour empêcher la ré-identification de la configuration de moniteur de tout Responsable du traitement individuel |
Exécuter le tracking d'attribution d'affiliation sur le site marketing (FirstPromoter — ne se déclenche que lorsque l'URL porte ?via=) |
Art. 6 (1)(a) + § 25 Abs. 1 TDDDG (en vigueur depuis le 14 mai 2024 en tant que successeur du TTDSG) — consentement via la bannière Datriva |
| Émettre des communications transactionnelles (compte, facturation, sécurité) | Art. 6 (1)(b) — contrat |
| Émettre les avis légalement requis (mises à jour de la confidentialité / des conditions au titre des Art. 12-14, notifications de violation de données à caractère personnel au titre de l'Art. 34) | Art. 6 (1)(c) — obligation légale |
| Envoyer des communications de mise à jour produit aux titulaires de compte existants (releases de fonctionnalités Uptimia, mises à jour pertinentes pour le service et annonces relatives à des services JJ Online similaires) | Art. 6 (1)(f) RGPD en combinaison avec le § 7 Abs. 3 UWG (Bestandskundenwerbung). Les quatre conditions cumulatives du § 7 Abs. 3 UWG sont toutes satisfaites : (i) votre adresse a été obtenue dans le cadre de la vente de nos biens ou services (inscription à un abonnement ou à un essai) ; (ii) nous utilisons l'adresse uniquement pour le marketing direct de nos propres produits et services similaires ; (iii) vous ne vous êtes pas opposé à cet usage — une fois que vous vous y opposez, tout envoi ultérieur de ce type cesse immédiatement ; et (iv) vous avez été clairement et de manière apparente informé, tant au moment où nous avons collecté votre adresse que dans chaque message ultérieur, que vous pouvez vous opposer à tout moment sans encourir de coûts au-delà des tarifs de transmission de base (Basistarif) — c'est-à-dire rien de plus que ce que le destinataire paierait pour renvoyer un message standard sur le support de transmission. L'opposition au titre de l'Art. 21 RGPD est inconditionnelle et traitée dès réception sans préjudice de votre contrat sous-jacent |
| Envoyer des communications marketing auxquelles vous avez consenti | Art. 6 (1)(a) — consentement |
| Respecter les obligations légales, répondre aux demandes licites | Art. 6 (1)(c) — obligation légale |
Pour chaque finalité fondée sur les intérêts légitimes, le résumé du test de mise en balance et votre droit d'opposition au titre de l'Art. 21 RGPD sont décrits au § 15. Une analyse des intérêts légitimes (AIL) pour l'une quelconque de ces activités est disponible sur demande à privacy@uptimia.com.
5. Services tiers que nous utilisons en qualité de responsable du traitement
Les services listés dans la présente section traitent les données à caractère personnel vous concernant en tant que titulaire d'un compte Uptimia sur nos instructions en qualité de responsable du traitement du Site et du Service. Lorsque Uptimia agit en outre en qualité de sous-traitant pour votre compte concernant les données à caractère personnel de vos propres visiteurs / utilisateurs finaux, les sous-traitants ultérieurs engagés pour ce rôle distinct sont listés au § 7 et à l'Annexe C du DPA.
La liste complète des Sous-traitants ultérieurs avec les adresses, les dates de DPA et les mécanismes de transfert figure à l'Annexe C du DPA. Le résumé ci-dessous est fourni à des fins de transparence au titre de l'Art. 13 (1)(e) RGPD.
5.1 Paiements et facturation
| Prestataire | Entité juridique | Localisation | Fonction | Mécanisme de transfert |
|---|---|---|---|---|
| Stripe | Stripe Payments Europe Ltd. | Irlande (+ sous-traitance ultérieure US par Stripe, Inc.) | Traitement des paiements d'abonnement, tokenisation de carte, détection de fraude | DPF UE-US + CCT en repli |
| PayPal | PayPal (Europe) S.à r.l. et Cie, S.C.A. | Luxembourg (+ sous-traitance ultérieure US) | Paiement alternatif au check-out | DPF UE-US + CCT en repli |
| easybill | easybill GmbH | Allemagne | Génération de factures, archivage de factures conforme GoBD | s/o (UE uniquement) |
5.2 Hébergement et infrastructure de base
| Prestataire | Entité juridique | Localisation | Fonction | Mécanisme de transfert |
|---|---|---|---|---|
| OVH | OVH SAS | France | Hébergement applicatif principal (tableau de bord, API, base de données applicative principale), réseau de sondes (région UE), base de données séries temporelles auto-hébergée | s/o (UE) |
| AWS — UE | Amazon Web Services EMEA SARL | Luxembourg (eu-central-1 Francfort + S3) | Courriel transactionnel via SES vers les destinataires UE ; stockage des PDF de factures et des exports dans S3 ; réseau de sondes (régions UE) | s/o (région UE Francfort) |
| AWS — US | Amazon Web Services, Inc. | États-Unis (us-east-1 Virginie) | Courriel transactionnel via SES vers les destinataires hors UE ; réseau de sondes (régions hors UE) | DPF UE-US + CCT en repli |
5.3 Réseau de sondes
Le réseau de sondes Uptimia est géographiquement réparti sur neuf prestataires. Propriété de conception importante : les sondes traitent le résultat du contrôle de manière transitoire en mémoire + en transit et suppriment immédiatement toute copie locale après avoir transmis le résultat à l'infrastructure principale située dans l'UE. Aucune Donnée à caractère personnel du Client n'est persistée au repos au niveau de la couche sonde.
| Prestataire | Entité juridique | Localisation | Mécanisme de transfert |
|---|---|---|---|
| OVH | OVH SAS | France | s/o (UE) |
| GCore | G-Core Labs S.A. | Luxembourg + régions mondiales | s/o régions UE ; CCT pour hors UE |
| DigitalOcean | DigitalOcean, LLC | États-Unis + régions | DPF UE-US + CCT en repli |
| Linode / Akamai | Akamai Technologies, Inc. | États-Unis + régions | DPF UE-US + CCT en repli |
| EDIS | EDIS Telekommunikation GmbH (opérant en tant que EDIS.at) | Klagenfurt, Autriche | s/o (UE) |
| Scaleway | Scaleway SAS (groupe Iliad) | France — régions de sondes en France (Paris), aux Pays-Bas (Amsterdam) et en Pologne (Varsovie) ; toutes UE | s/o (UE) |
| AWS | comme ci-dessus (5.2) | UE + États-Unis | s/o UE ; DPF + CCT US |
| Contabo | Contabo GmbH | Allemagne (siège à Munich) — régions de sondes en UE (Allemagne, Autriche, Espagne, Portugal) et hors UE (États-Unis, Royaume-Uni, Singapour, Japon, Australie, Inde) | s/o régions UE (Contabo GmbH est l'entité contractante UE) ; CCT pour les régions hors UE, avec la propriété de traitement éphémère décrite au § 7 (Annexe B.6 du DPA) comme mesure supplémentaire qui empêche le stockage persistant de Données à caractère personnel du Client sur les hôtes de sondes indépendamment de la région |
| Vultr | Vultr Holdings, LLC (The Constant Company, LLC) | États-Unis (Delaware) — 13 emplacements de sondes aux États-Unis, Pays-Bas, Allemagne, Royaume-Uni, Australie, Japon | Pas de certification DPF — CCT + la propriété de traitement éphémère décrite ci-dessus comme principale mesure supplémentaire. Vultr fournit de l'IaaS brut et ne garantit pas contractuellement une propriété d'absence de stockage persistant pour l'usage spécifique des serveurs par un client donné ; la propriété de traitement éphémère est donc une mesure technique et organisationnelle au niveau du déploiement JJ Online (aucune persistance au niveau applicatif sur les disques Vultr ; entrées et sorties des contrôles détenues uniquement en mémoire et en transit ; le binaire de la sonde n'écrit aucune Donnée à caractère personnel du Client sur le disque local) mise en œuvre par nous en qualité de responsable, et documentée comme telle à l'Annexe B.6 du DPA. Nous vérifions périodiquement la propriété — au moins trimestriellement et à chaque modification du binaire de la sonde ou de sa configuration de déploiement — en échantillonnant les hôtes de sondes, en listant les écritures sur disque local par rapport à une liste de refus des chemins que le binaire de la sonde est autorisé à toucher, et en confirmant qu'aucune Donnée à caractère personnel du Client n'a été écrite sur le disque ; le journal de vérification fait partie du registre de test régulier au titre de l'Art. 32 (1)(d) que nous tenons et est productible sur demande de l'autorité de contrôle. Le DPA Vultr lui-même reste le DPA prestataire standard et n'est pas invoqué pour démontrer cette mesure. |
5.4 Authentification
| Prestataire | Entité juridique | Localisation | Fonction | Mécanisme de transfert |
|---|---|---|---|---|
| Auth0 | Auth0 EMEA Limited (groupe Okta) | Irlande (+ sous-traitance ultérieure US) | Gestion des identités, flux de connexion, orchestration des connexions sociales | DPF UE-US + CCT en repli |
Sous-sous-traitants ultérieurs pour les connexions sociales Auth0. Lorsque vous choisissez de vous connecter avec Google ou GitHub sur la page de connexion hébergée par Auth0, Auth0 transfère le flux OAuth à ces prestataires. Il n'existe aucune intégration OAuth directe entre Uptimia et Google ou GitHub ; Auth0 détient le DPA sous-jacent. Les prestataires sont : Google Ireland Limited (avec sous-traitance ultérieure US par Google LLC) et GitHub, Inc. (groupe Microsoft).
Cookies pendant le flux de connexion. La page de connexion hébergée par Auth0 fixe ses propres cookies strictement nécessaires sur le domaine Auth0 (non sur uptimia.com) pendant l'authentification. Ces cookies sont nécessaires à l'achèvement de la connexion que vous avez demandée et sont exemptés du consentement au titre du § 25 Abs. 2 Nr. 2 TDDDG. Les boutons « Se connecter avec Google » et « Se connecter avec GitHub » de nos pages de connexion et d'inscription utilisent un schéma click-to-load : aucun script Auth0, Google ou GitHub n'est chargé, et aucune requête à ces prestataires n'est effectuée, tant que vous n'avez pas cliqué sur l'un de ces boutons ; le détail complet et l'URL de confidentialité Auth0 / Okta figurent dans notre Politique relative aux cookies § 4.8.
5.5 Sécurité et renseignement sur les menaces
| Prestataire | Entité juridique | Localisation | Fonction | Mécanisme de transfert |
|---|---|---|---|---|
| Google Web Risk API | Google Ireland Limited | Irlande (+ sous-traitance ultérieure US) | Filtrage anti-malware / anti-hameçonnage des URL surveillées — seule l'URL est envoyée | DPF UE-US + CCT en repli |
| Google PageSpeed Insights | Google Ireland Limited | Irlande (+ sous-traitance ultérieure US) | Analyse de performance pour le moniteur Speed — seule l'URL est envoyée | DPF UE-US + CCT en repli |
5.6 Intégrations de pages marketing
| Prestataire | Entité juridique | Localisation | Fonction | Mécanisme de transfert |
|---|---|---|---|---|
| FirstPromoter | Igil Webs SRL | Roumanie | Attribution d'affiliation sur les pages marketing uptimia.com — ne se déclenche que lorsque l'URL porte ?via= ; conditionné à votre consentement via la bannière cookies Datriva |
s/o (UE) |
5.7 Services internes inter-produits JJ Online (même responsable — non sous-traitants ultérieurs au sens de l'Art. 28)
Les services suivants sont exploités par JJ Online GmbH elle-même et ne sont pas des sous-traitants ultérieurs au sens de l'Article 28. Tous les cinq tournent sur la même empreinte UE que l'application Uptimia principale — OVH France (base de données applicative et services auto-hébergés) et, lorsque le stockage objet est requis, AWS Francfort eu-central-1 — sous les mêmes mesures techniques et organisationnelles au titre de l'Art. 32 décrites au § 12. Aucun traitement par un produit-sœur JJ Online ne quitte l'UE.
- Bannière CMP Datriva — gestion du consentement aux cookies sur le site marketing (
https://datriva.com/cdn/banner/uptimia.js). Hébergée chez OVH France. - Widget HelpCanvas — support de chat in-app sur le site marketing. L'application HelpCanvas et son magasin de messages sont hébergés chez OVH France sous la pile JJ Online ; les transcriptions de chat HelpCanvas ne quittent pas l'UE.
- Base de données séries temporelles auto-hébergée — stockage de séries temporelles pour les mesures de monitoring, exploitée par JJ Online sur l'infrastructure OVH France.
- Altcha — bibliothèque captcha à preuve de travail exécutée localement sur l'infrastructure Uptimia ; aucun flux de données vers un tiers.
- ErrorHawk (produit-sœur) — hors champ de production : le DSN est configuré uniquement dans notre environnement de développement interne, non sur l'infrastructure de production
uptimia.com. Aucune Donnée à caractère personnel du Client n'est transmise à ErrorHawk en production. La propre pile de production d'ErrorHawk, lorsque pertinente pour d'autres produits JJ Online, tourne également chez OVH France.
Divulgation à des tiers — pas de revente, pas d'entraînement IA, pas de constitution d'audiences. Nous ne divulguons pas vos données à caractère personnel à des tiers pour leurs propres finalités commerciales. Les services tiers des § 5.1-5.6 traitent vos données à caractère personnel uniquement en qualité de nos sous-traitants ultérieurs, sur nos instructions documentées, sous accords écrits de traitement de données qui interdisent contractuellement à chaque sous-traitant ultérieur d'utiliser vos données à caractère personnel à toute finalité au-delà du service spécifique qu'il accomplit pour notre compte. Les usages secondaires interdits incluent, sans limitation :
- L'entraînement de modèles d'intelligence artificielle, d'apprentissage automatique ou de grands modèles de langage — y compris le pré-entraînement de modèles de fondation, le fine-tuning, l'extraction d'embeddings, l'indexation pour la génération augmentée par récupération, la constitution de jeux d'évaluation ou toute autre incorporation de vos données à caractère personnel dans des jeux de données dérivés ou des poids de modèle, que ce soit par le sous-traitant ultérieur ou par tout tiers à qui le sous-traitant ultérieur sous-licencie en aval
- La publicité, le profilage, la constitution d'audiences similaires, le ciblage publicitaire ou l'enrichissement de segments d'audience
- La revente, la sous-licence ou la syndication de vos données à caractère personnel — qu'elle soit sur une base nominative, pseudonymisée, hachée ou agrégée — à des contreparties courtiers en données, réseaux d'analyses ou réseaux publicitaires
- Tout autre usage secondaire qui n'est pas nécessaire pour fournir le service contracté à notre profit
Les restrictions de l'Art. 28 (3) dans l'accord de traitement de données de chaque sous-traitant ultérieur constituent le mécanisme d'application des interdictions ci-dessus. Lorsque les conditions standard ou le DPA d'un sous-traitant ultérieur ne couvrent pas adéquatement ces interdictions, nous négocions soit des conditions modifiées avant de l'instruire, soit nous n'engageons pas le sous-traitant ultérieur.
6. Autres destinataires — fiscalité, audit, juridique, fusions-acquisitions et demandes licites
Au-delà des sous-traitants ultérieurs au quotidien du § 5, conformément à l'Art. 13 (1)(e) RGPD et aux Lignes directrices du CEPD sur la transparence (WP260 rev. 01), nous pouvons également divulguer des données à caractère personnel aux catégories de destinataires suivantes :
| Catégorie de destinataire | Quand | Base juridique | Périmètre |
|---|---|---|---|
| Administrations fiscales (Finanzamt ; équivalents dans d'autres juridictions) | Déclarations fiscales périodiques, contrôles de conformité, demandes d'informations licites | Art. 6 (1)(c) — § 147 AO, § 257 HGB | Limité aux données de transaction, de facturation et comptables exigées par la loi |
| Auditeurs externes (légaux, volontaires, due diligence acquéreur) | Audit annuel, audit financier ou de sécurité volontaire, due diligence pré-acquisition | Art. 6 (1)(c) lorsque mandaté ; sinon Art. 6 (1)(f) | Sous obligations écrites de confidentialité professionnelle ; minimisé au périmètre de la mission |
| Conseil juridique (avocats externes, notaires) | Défense de réclamations, litiges contractuels, réponse réglementaire, conseil transactionnel | Art. 6 (1)(f) ; confidentialité professionnelle au titre du § 203 StGB | Minimisé au périmètre de l'instruction |
| Acquéreurs potentiels et leurs conseils (M&A, investissement, cession d'actifs, restructuration) | Opérations sur capital — data rooms de due diligence, conventions de cession d'actions, cessions d'actifs | Art. 6 (1)(f), interprété conformément au Beschluss « Datenschutz im Asset Deal » de la DSK du 11 septembre 2024 (qui a remplacé et étendu le papier original de la DSK du 24 mai 2019). En particulier, nous appliquons la structure phase par phase du Beschluss : dans la phase de due diligence, les données à caractère personnel des clients ne sont en principe mises à disposition que sous forme pseudonymisée ou agrégée, la divulgation des données identifiantes étant limitée à l'exception étroite tardive au titre de l'Art. 6 (1)(f) que le Beschluss reconnaît (LOI signée / négociations avancées, NDA en place, minimisation à ce qui est strictement nécessaire pour les questions de diligence restantes de l'acquéreur, pas de déversement large de data room) ; dans la phase de closing / transfert, nous suivons la voie de base juridique que le Beschluss prescrit pour la structure de transaction concernée, et en particulier nous traitons la vente d'une base de données clients comme un actif autonome comme le cas plus sensible qui, selon l'analyse du Beschluss, exige généralement soit le consentement, soit un processus significatif d'information et d'opposition préalable au transfert, distinct du cas où les relations clients sont transférées de manière incidente dans le cadre d'une cession d'actifs plus large d'entreprise en exploitation. À travers les deux phases, l'évolution du Beschluss d'une pure Widerspruchslösung post-closing vers une information préalable au transfert des personnes concernées affectées est reflétée dans la colonne des garanties | NDA écrit, minimisation de la data room, pseudonymisation ou agrégation pendant la due diligence (avec divulgation des données identifiantes uniquement au titre de l'exception étroite tardive au titre de l'Art. 6 (1)(f), sur la base du besoin d'en connaître et seulement après franchissement du seuil LOI / négociation avancée), et information préalable au transfert des personnes concernées affectées conformément au Beschluss du 11 septembre 2024 plutôt qu'un simple opt-out post-transfert — avec le scénario de la base de données clients autonome traité sur la voie de base juridique plus protectrice que le Beschluss spécifie pour ce cas |
| Forces de l'ordre, tribunaux, régulateurs | Demande licite — décision de justice, citation à comparaître, enquête réglementaire | Art. 6 (1)(c) lorsque contraignant ; Art. 6 (1)(f) pour la coopération volontaire vérifiée | Limité au périmètre de la demande spécifique ; nous contestons les demandes trop larges lorsque la loi le permet |
| Compagnies d'assurance et administrateurs de sinistres | Réclamations en responsabilité civile professionnelle, cyber-assurance, responsabilité commerciale | Art. 6 (1)(f) | Minimisé aux données à caractère personnel nécessaires pour évaluer et traiter la réclamation spécifique |
Aucun de ces destinataires ne reçoit de données à caractère personnel de manière routinière ou à grande échelle ; chaque divulgation est déclenchée par un événement spécifique.
7. Uptimia en qualité de sous-traitant pour les données de vos visiteurs / utilisateurs finaux
Lorsque vous utilisez Uptimia pour surveiller des ressources que vous exploitez, certains flux de traitement surviennent dans lesquels vous êtes le responsable du traitement des données à caractère personnel de vos visiteurs ou utilisateurs finaux et Uptimia est le sous-traitant agissant pour votre compte :
| Flux | Quelles données à caractère personnel transitent par Uptimia |
|---|---|
| Contrôles HTTP authentifiés | Les corps de réponse des URL que vous configurez peuvent contenir des noms d'utilisateur, des adresses électroniques ou d'autres données à caractère personnel de vos utilisateurs finaux — captés dans nos instantanés de réponse de contrôle (TTL de 7 jours sur le champ corps-de-réponse) |
| Monitoring transactionnel | Les captures d'écran prises à chaque étape d'un script de transaction peuvent contenir des données à caractère personnel visibles sur des pages authentifiées (par ex. le nom d'un utilisateur connecté dans la barre de navigation) — stockées sous la période de conservation indiquée au § 11 |
| Real User Monitoring (RUM) | Lorsque vous déployez notre script RUM sur des URL que vous sélectionnez, il renvoie des chronométrages de chargement de page, des métadonnées de navigateur et d'appareil, l'origine géographique et des événements d'erreur JavaScript ; les adresses IP des visiteurs sont tronquées à /24 en IPv4 et /48 en IPv6 avant stockage ; les événements ne sont persistés que sous forme agrégée — il n'y a pas d'enregistrement par balise d'un visiteur individuel |
| Abonnements aux incidents de page d'état | Adresses électroniques que vos visiteurs saisissent pour s'abonner aux notifications d'incidents sur une page d'état que vous exploitez via Uptimia |
Répartition responsable / sous-traitant — l'analyse moyens essentiels / non essentiels. L'Art. 28 RGPD impose au responsable de déterminer les finalités et les moyens du traitement et au sous-traitant d'agir sur les instructions documentées du responsable. Les Lignes directrices 07/2020 du CEPD sur les notions de responsable du traitement et de sous-traitant (§ 38) tracent une frontière nette entre les moyens essentiels — quelles catégories de données sont traitées, quelles catégories de personnes concernées, la durée de conservation, les destinataires des données — que le responsable doit déterminer et les moyens non essentiels — choix d'implémentation techniques tels que l'algorithme, le format, le logiciel, le matériel — que le sous-traitant est libre de déterminer. Nous sommes le sous-traitant des données à caractère personnel de vos visiteurs / utilisateurs finaux selon l'analyse suivante :
- Les finalités sont les vôtres. Vous décidez de déployer ou non notre script RUM et sur quelles URL, de surveiller ou non un point de terminaison authentifié, de scripter ou non un parcours de transaction et d'exploiter ou non une page d'état publique qui prend des abonnements de visiteurs. Aucune de ces opérations de traitement ne commence tant que vous ne l'initiez pas.
- Les moyens essentiels sont les vôtres. Votre choix de déploiement détermine la catégorie de données (déployer RUM = événements de chargement de page de vos visiteurs ; configurer le monitoring transactionnel = captures d'écran du parcours que vous avez scripté) ; les catégories de personnes concernées sont déterminées par qui visite vos sites et pour qui vous scriptez le parcours ; la durée de conservation est déterminée par votre niveau de formule de Service (voir § 11 et la matrice par formule sur uptimia.com) ; les destinataires des données sont limités par l'isolation de votre compte et par les sous-traitants ultérieurs documentés à l'Annexe C du DPA, auxquels vous consentez en déployant.
- Les moyens non essentiels sont les nôtres. La troncature à /24 en IPv4 et /48 en IPv6 des adresses IP des visiteurs avant stockage, la logique d'agrégation qui maintient les événements RUM hors des tables par balise, le choix d'une infrastructure de stockage située dans l'UE (OVH France pour la base de données applicative, AWS Francfort
eu-central-1pour les blobs de captures d'écran dans S3) et la propriété de traitement éphémère de la couche sonde sont des choix d'implémentation techniques que nous faisons en qualité de sous-traitant. Ils constituent des mesures techniques et organisationnelles au titre de l'Art. 32 RGPD — ils renforcent votre contrôle sur les moyens essentiels plutôt qu'ils ne le déplacent.
Selon cette analyse, les quatre flux ci-dessus sont des relations claires de responsable-à-sous-traitant au sens de l'Art. 28. Notre DPA intègre les conditions de responsable-à-sous-traitant requises par l'Art. 28 (3) RGPD ; le déploiement du Service (déploiement de script, configuration de moniteur, sélection du niveau de formule), les instructions documentées du DPA et le Résumé des Instructions de Traitement par compte décrit au § 6.1(e) du DPA et à l'Annexe A.8 constituent ensemble vos instructions documentées aux fins de l'Art. 28 (3)(a) RGPD. Le DPA s'applique automatiquement par renvoi en vertu du § 17.2 des CGU Uptimia lorsque vous commencez à utiliser les fonctionnalités de monitoring qui traitent des données à caractère personnel de vos visiteurs / utilisateurs finaux ; aucune signature distincte n'est requise pour mettre le DPA en vigueur.
Art. 28 (9) RGPD — forme écrite / électronique. L'Art. 28 (9) RGPD exige que le contrat responsable-sous-traitant soit « par écrit, y compris en format électronique ». Les Conditions générales d'utilisation Uptimia dans lesquelles le DPA est intégré sont elles-mêmes en format électronique, et le texte intégral du DPA est publié à une URL stable et persistante sur uptimia.com (actuellement https://uptimia.com/legal/dpa — la même surface canonique depuis laquelle la présente Politique de confidentialité est publiée) et vous est accessible au moment de l'intégration, à la fois avant et pendant votre acceptation des CGU. Votre acceptation électronique des CGU — en vous inscrivant, en payant ou en utilisant autrement le Service d'une manière qui engage des fonctionnalités de monitoring traitant des données à caractère personnel de vos visiteurs / utilisateurs finaux — constitue votre signature du DPA aux fins de l'Art. 28 (9) RGPD. La voie « exemplaire contre-signé sur demande » du paragraphe suivant est donc un accommodement aux préférences de forme de procurement, non une condition préalable à la mise en vigueur du DPA ; le DPA est pleinement contraignant au titre de l'Art. 28 (9) sur la seule acceptation électronique.
Instructions documentées par compte. Vous pouvez demander le Résumé des Instructions de Traitement par compte à tout moment en écrivant à privacy@uptimia.com. Le Résumé est généré à partir de l'état de votre compte au moment de la demande et liste, pour votre compte spécifique : les types de moniteurs actifs, les URL et ressources que vous avez choisies de surveiller, votre niveau de formule de Service et les durées de conservation qui en découlent, les canaux d'alerte que vous avez activés (et donc les Sous-traitants ultérieurs actifs sur votre compte), la région de stockage UE applicable à vos données et toutes instructions écrites ultérieures que nous avons acceptées de vous. Nous retournons le Résumé dans les cinq (5) jours ouvrés. Le Résumé est documentaire — il ne modifie pas le DPA — et est destiné à soutenir votre obligation au titre de l'Art. 30 (1) de tenir un registre des activités de traitement et la responsabilité au titre de l'Art. 5 (2) lorsque vous traitez des données à caractère personnel de vos visiteurs / utilisateurs finaux à travers le Service. La génération en libre-service du Résumé dans votre tableau de bord figure sur la feuille de route produit ; en attendant, le processus manuel s'applique.
Exemplaire signé du DPA. Lorsque votre processus de procurement, d'audit ou réglementaire exige un exemplaire contre-signé de notre DPA avec le Résumé des Instructions de Traitement annexé en Annexe A.8, nous l'exécuterons sur demande sans frais. Contactez privacy@uptimia.com.
Sous-traitants ultérieurs côté visiteur. Les sous-traitants ultérieurs engagés pour le rôle de sous-traitant sont listés à l'Annexe C du DPA. Ils sont un sur-ensemble des sous-traitants ultérieurs du § 5 ci-dessus. Les entrées supplémentaires de l'Annexe C.5 sont les canaux d'alerte que vous configurez (Slack, Discord, Twilio, PagerDuty, etc.), qui deviennent des Sous-traitants ultérieurs uniquement dans la mesure où la charge utile de l'alerte inclut des données à caractère personnel de visiteurs / utilisateurs finaux qui vous appartiennent (comme indiqué au § 3 « Configurations des canaux de notification — double rôle des canaux d'alerte » ci-dessus), et uniquement lorsque vous activez effectivement le canal. Les mêmes tiers agissent également en qualité de propres prestataires de service d'Uptimia à l'égard des enregistrements de contacts et identifiants de l'équipe ops et du composant alerte-adressée-à-votre-équipe-ops du même flux — c'est ce volet de relation en qualité de responsable qui est inventorié au § 5, non ici. La liste de l'Annexe C.5 est donc plus étroite que la liste canal par canal du § 5 : c'est la projection du rôle de sous-traitant du même ensemble de tiers.
Garanties techniques pour les flux en rôle de sous-traitant.
- Les adresses IP des visiteurs RUM sont tronquées à /24 (IPv4) ou /48 (IPv6) avant que l'événement ne soit écrit en stockage ; l'adresse IP complète n'est jamais persistée
- Les événements RUM ne sont persistés que sous forme agrégée — il n'y a pas de table par balise, et aucun visiteur individuel ne peut être reconstruit à partir des données stockées
- Les captures d'écran transactionnelles et les instantanés de réponse de contrôle sont stockés sur AWS S3 (Francfort) sous notre compte ; l'accès est conditionné par l'authentification du compte de référence
- Les nœuds de sondes traitent les entrées et sorties des contrôles uniquement de manière éphémère ; aucune Donnée à caractère personnel du Client n'est persistée au repos sur la couche sonde
- Les identifiants et secrets que vous fournissez pour que le Service puisse s'authentifier à vos ressources (identifiants HTTP Basic, en-têtes de requête personnalisés, identifiants d'intégration, valeurs littérales d'étapes de monitoring transactionnel) sont conservés sous chiffrement enveloppe au niveau colonne avec des clés gérées séparément, comme décrit au § 12
Consentement du visiteur. Il vous incombe en tant que responsable du traitement d'obtenir tout consentement requis de vos visiteurs avant de déployer notre script RUM sur votre site web. Lorsque le § 25 TDDDG ou un droit national de l'UE équivalent exige le consentement pour le stockage ou l'accès à des informations sur le terminal du visiteur, vos visiteurs doivent se voir offrir une opportunité de consentement conforme au § 25 avant que notre script RUM ne se charge. Nous fournissons de la documentation sur l'intégration du conditionnement au consentement ; la mise en œuvre est de votre ressort.
8. Profilage et prise de décision automatisée
La présente section divulgue les activités automatisées que le Service exploite et qui satisfont à la définition du profilage au sens de l'Art. 4 (4) RGPD, comme l'exigent les Art. 13 (2)(f) et 15 (1)(h) RGPD — y compris la seule activité qui satisfait à la définition d'une décision automatisée au sens de l'Art. 22 (1) RGPD.
Décision automatisée de fraude au paiement au check-out (Art. 22 (1) RGPD). Lorsque vous soumettez un paiement, notre prestataire de paiement évalue la transaction par rapport à des signaux comprenant le moyen de paiement, l'empreinte de l'appareil, l'adresse de facturation, l'adresse IP, l'historique d'utilisation antérieur et des schémas d'apprentissage automatique tirés du corpus de fraude plus large du prestataire, afin de produire un score de risque de fraude. Un score suffisamment élevé entraîne le refus de la transaction, son signalement pour examen manuel par le prestataire ou son acheminement vers une vérification supplémentaire telle que 3-D Secure. Il s'agit d'une décision exclusivement automatisée qui, en empêchant l'achat de s'achever en temps réel, a des effets sur vous suffisamment significatifs pour relever de l'Art. 22 (1) RGPD.
L'analyse ici est répartie entre (i) la base juridique du traitement sous-jacent de vos données de paiement (Art. 6 RGPD) et (ii) la passerelle de l'Art. 22 (2) RGPD qui autorise la décision automatisée elle-même. Suivant la lecture étroite du CEPD de « nécessaire à l'exécution du contrat » dans ses Lignes directrices sur l'Article 22 (et la ligne renforcée dans le commentaire post-SCHUFA Holding (CJUE C-634/21, 7 déc. 2023)), nous nous appuyons sur les bases statutaires et ne traitons la nécessité contractuelle que comme repli.
Base juridique du traitement sous-jacent — Art. 6 (1)(c) RGPD (principal). Le traitement est nécessaire à la conformité du prestataire de paiement aux exigences d'authentification forte du client de la DSP2 (Directive (UE) 2015/2366 et Règlement délégué (UE) 2018/389 de la Commission), aux régimes de lutte contre le blanchiment de capitaux / financement du terrorisme (Directive (UE) 2015/849 telle que modifiée ; Règlement AML de l'UE ; actes nationaux de transposition) et à l'obligation des Lignes directrices de l'ABE EBA/GL/2017/17 sur les mesures de sécurité pour les risques opérationnels et de sécurité des services de paiement d'appliquer des mécanismes de surveillance des transactions qui détectent les transactions de paiement frauduleuses. Ces obligations statutaires lient directement le prestataire de paiement et transitent jusqu'à nous en tant que commerçant pour le compte duquel le filtrage est opéré ; elles rendent le traitement nécessaire au respect d'une obligation légale à laquelle Uptimia (par l'intermédiaire du prestataire) est soumise au sens de l'Art. 6 (1)(c) RGPD.
Art. 6 (1)(f) RGPD — base alternative pour l'intérêt résiduel de prévention de la fraude côté commerçant. Dans la mesure où tout élément du filtrage va au-delà de ce qui est strictement requis par le cadre statutaire ci-dessus et reflète notre propre intérêt côté commerçant à prévenir la fraude carte-non-présente, les rétrofacturations et la prise de contrôle de compte à l'inscription, nous nous appuyons sur l'Art. 6 (1)(f) RGPD. La mise en balance des intérêts légitimes pour cet élément résiduel est documentée au § 15 (« Résumé de l'Analyse des Intérêts Légitimes ») et traite l'intérêt comme substantiel (perte de fraude directe + charge de traitement des litiges), les intérêts de la personne concernée comme protégés par les garanties de l'Art. 22 (3) ci-dessous, et le traitement comme proportionné (signaux par transaction, non conservés comme profil).
Art. 6 (1)(b) RGPD — base de nécessité contractuelle, repli uniquement. Lorsque ni l'encadrement statutaire ni l'encadrement de l'intérêt résiduel n'atteint un élément spécifique du traitement, le filtrage est également nécessaire pour nous permettre d'entrer dans le volet paiement du contrat que vous cherchez à conclure avec nous, soutenant l'Art. 6 (1)(b). Nous listons ceci comme un repli parce que nous partageons l'avis du CEPD selon lequel la « nécessité » de l'Art. 6 (1)(b) doit être lue étroitement : le fait que le filtrage anti-fraude soit opérationnellement indispensable ne satisfait pas à lui seul au test « pas d'alternative moins intrusive », et les bases ci-dessus aux Art. 6 (1)(c) et (f) sont l'histoire plus propre.
Passerelle de l'Art. 22 (2) pour la décision automatisée elle-même. L'Art. 6 seul n'autorise pas la décision automatisée au sens de l'Art. 22 (1) ; cette décision a besoin d'une passerelle de l'Art. 22 (2) — (a) nécessité contractuelle, (b) droit de l'Union ou de l'État membre habilitant qui prévoit des garanties appropriées, ou (c) consentement explicite. Nous nous appuyons principalement sur l'Art. 22 (2)(b) RGPD : le cadre SCA de la DSP2 (Directive (UE) 2015/2366 lue avec le Règlement délégué (UE) 2018/389 de la Commission) et le cadre AML/CFT cité ci-dessus constituent un droit de l'Union habilitant qui requiert les décisions de surveillance des transactions prises au check-out et qui prévoit lui-même les garanties appropriées pour la personne concernée (chapitre de protection du consommateur du Titre IV de la DSP2 ; mécanismes de réclamation et d'examen de l'AMLD dans la transposition nationale ; garanties de la personne concernée au titre de l'Art. 22 (3) RGPD appliquées en parallèle). Les Lignes directrices de l'ABE citées ci-dessus opérationnalisent ce régime statutaire à travers des attentes prudentielles contraignantes sur les décisions de surveillance des paiements. Nous traitons l'Art. 22 (2)(a) RGPD (nécessité contractuelle) comme une passerelle Art. 22 de repli uniquement — engagée si et dans la mesure où une autorité de contrôle lirait étroitement la passerelle de droit habilitant de l'Art. 22 (2)(b) — et nous ne nous appuyons pas sur l'Art. 22 (2)(c) (consentement explicite), qui ne serait pas librement donné dans un contexte de check-out de paiement.
Vos garanties au titre de l'Art. 22 (3) RGPD. Vous avez le droit :
- d'obtenir une intervention humaine dans la décision — écrivez à privacy@uptimia.com en identifiant la transaction refusée ; nous orienterons le dossier vers l'équipe d'examen manuel du prestataire de paiement et nos propres opérations de facturation, qui peuvent tous deux annuler le résultat automatisé sur les faits ;
- d'exprimer votre point de vue — vous pouvez soumettre tout contexte que vous jugez pertinent (par ex. contexte de voyage pour un refus IP-étranger, détails de facturation corrigés, preuve de propriété de carte) ;
- de contester la décision — le résultat de l'examen manuel est lui-même susceptible de réexamen par nous ; si vous restez insatisfait, vous pouvez utiliser la voie de check-out alternative (Stripe ↔ PayPal) ou demander une explication écrite apte à être transmise à votre émetteur de carte ;
- de recevoir le code de motif de refus spécifique et, le cas échéant, le nom de la règle Stripe Radar — sur demande au titre de l'Art. 22 (3), nous vous communiquerons, en plus des étapes d'examen humain ci-dessus, le code de motif de refus retourné par le prestataire de paiement pour votre transaction et, lorsque le refus a été motivé par une règle Radar spécifique que le prestataire nous a fait apparaître dans le tableau de bord marchand (par opposition à un refus de banque émettrice), le nom de cette règle. Il s'agit de la divulgation par décision des principales raisons décrite sous « Informations utiles sur la logique impliquée » ci-dessous ; nous rendons l'engagement explicite ici afin qu'il soit atteignable depuis la liste des garanties de l'Art. 22 (3) sans avoir à lire d'abord le paragraphe d'implémentation SCHUFA.
Nous répondrons à toute demande au titre de l'Art. 22 (3) dans le délai de l'Art. 12 (3) RGPD (un mois, prorogeable de deux mois supplémentaires pour les cas complexes avec notification à vous).
Informations utiles sur la logique impliquée (Art. 15 (1)(h) RGPD ; CJUE Affaire C-634/21 SCHUFA Holding, 7 déc. 2023). Le score de risque de fraude est produit par un modèle d'apprentissage automatique tiers maintenu par le prestataire de paiement (Stripe Radar ; le modèle PayPal équivalent) et calibré contre le corpus de fraude mondial de ce prestataire. Les poids internes de ces modèles ne sont pas publiés par le prestataire et ne nous sont pas mis à disposition selon les conditions standard de commerçant — exposer les poids permettrait aux fraudeurs de procéder à de la rétro-ingénierie du modèle, c'est pourquoi aucun prestataire de paiement par carte d'importance ne les divulgue. Nous ne considérons pas que cette absence fasse échec à votre droit au titre de l'Art. 15 (1)(h). SCHUFA Holding exige des « informations utiles sur la logique impliquée » suffisantes pour permettre à la personne concernée de comprendre la procédure qui a conduit au score et, le cas échéant, de contester la décision spécifique dans son cas — non l'algorithme lui-même. Selon cette norme, nous divulguons, et sur demande confirmerons par écrit :
- Les principaux groupes de facteurs que le modèle évalue — montant et devise de la transaction ; métadonnées du moyen de paiement (BIN de carte, pays d'émission, marque, type de financement) ; résultat de la vérification d'adresse de facturation AVS ; empreinte d'appareil et de navigateur ; adresse IP, géolocalisation IP et incompatibilité IP / pays-de-facturation ; résultats antérieurs pour la même carte ou le même compte dans le corpus mondial du prestataire et chez Uptimia (votre propre historique avec nous) ; signaux de réputation au niveau réseau et listes de blocage ; résultat 3-D Secure lorsque disponible.
- La principale raison de votre résultat spécifique. Si votre transaction a été refusée, le prestataire retourne un code de motif de refus spécifique (par exemple
do_not_honor,card_declined,fraudulent,lost_card,stolen_card,pickup_card,incorrect_cvc,expired_card) et, lorsque le refus a été motivé par une règle Radar plutôt que par la banque émettrice, le nom de la règle qui s'est déclenchée (visible pour nous dans le tableau de bord marchand). Nous vous transmettrons ce code spécifique et, lorsque disponible, le nom de règle spécifique sur demande — il s'agit de la divulgation des principales raisons requise par SCHUFA Holding § 54-§ 59. - La voie de dérogation que nous contrôlons en tant que commerçant. Un refus de fraude côté prestataire ne vous verrouille pas hors du Service. Nous pouvons choisir d'honorer une transaction que le modèle a refusée ; écrivez à privacy@uptimia.com en identifiant la transaction, fournissez tout contexte que vous jugez pertinent (voyage, détails de facturation corrigés, preuve de propriété de carte), et nous (a) escaladerons auprès de l'équipe d'examen manuel du prestataire, qui peut annuler le modèle sur les faits, et (b) retenterons la charge depuis notre côté commerçant après la dérogation, ou utiliserons la voie de check-out alternative (Stripe ↔ PayPal).
- Importance pour vous. Un score suffisamment élevé soit refuse la transaction au check-out, soit déclenche une élévation 3-D Secure, soit oriente la transaction vers un examen manuel chez le prestataire. Le score n'est pas conservé comme un profil dans votre enregistrement utilisateur ; c'est un signal par transaction.
Limites de débit anti-abus et scoring de bots à l'inscription (pas de décision Art. 22). Distinct de la fraude au paiement, nous appliquons des décisions automatisées de limitation de débit contre les points de terminaison API et d'inscription en fonction des schémas de requêtes, de la réputation de l'IP et de l'âge du compte. L'inscription est en outre conditionnée par Altcha, un défi à preuve de travail auto-hébergé exécuté localement sur l'infrastructure Uptimia (aucun flux de données vers un tiers). Un score heuristique interne est également enregistré dans votre enregistrement utilisateur. Ces signaux sont indicatifs uniquement — il n'y a pas de logique d'auto-suspension ou d'auto-refus. Les comptes sont désactivés manuellement par un administrateur après examen humain. L'inscription est limitée à 3 tentatives par 15 minutes par IP. La décision est réversible en écrivant à privacy@uptimia.com.
Transparence du profilage pour l'heuristique indicative (Art. 4 (4), Art. 13 (2)(f), Art. 14 (2)(g), Art. 15 (1)(h) RGPD). Le score heuristique indicatif sur votre enregistrement utilisateur est du profilage au sens de l'Art. 4 (4) RGPD même si aucune décision exclusivement automatisée produisant des effets juridiques ou significatifs similaires n'est prise sur sa base (l'Art. 22 (1) RGPD n'est pas engagé). Les obligations de transparence au titre des Art. 13 (2)(f) et 14 (2)(g) — et le droit d'accès correspondant aux « informations utiles sur la logique impliquée » au titre de l'Art. 15 (1)(h) — ne sont, selon la meilleure lecture, pas strictement limités au profilage de l'Art. 22 (1) ; nous divulguons donc, à la fois ici à l'avance et sur demande d'accès, les principales catégories d'entrées que l'heuristique évalue : taux de tentatives d'inscription ou de connexion depuis la même IP et le même domaine d'adresse électronique sur une fenêtre définie ; présence de l'IP sur des listes de réputation internes et externes bien connues (par ex. agrégateurs de listes open-proxy / sortie Tor / VPN connus) ; signaux d'âge et d'état de compte (nouvellement créé vs ancien, historique antérieur de tickets de support) ; similarité de schéma avec des empreintes d'abus connues (taux d'échec de preuve de travail via Altcha, schéma de création de moniteurs dans les minutes suivant l'inscription). Sur demande d'accès au titre de l'Art. 15 (1)(h), nous divulguerons en outre le score enregistré sur votre compte, les principaux contributeurs à ce score et l'absence de toute règle d'auto-décision attachée à celui-ci.
Votre droit d'opposition au titre de l'Art. 21 RGPD. Vous conservez le droit de vous opposer à tout profilage fondé sur nos intérêts légitimes (Art. 6 (1)(f) RGPD). Ce droit ne s'étend toutefois pas à la décision de fraude au paiement décrite ci-dessus dans la mesure où cette décision repose sur la passerelle de droit habilitant de l'Art. 22 (2)(b) et sur la base de conformité statutaire de l'Art. 6 (1)(c) — aucune des deux n'engage l'Art. 21. Pour l'élément résiduel de l'Art. 6 (1)(f) du filtrage, l'Art. 21 s'applique mais la mise en balance des intérêts légitimes consignée au § 15 l'emporterait en pratique sur une opposition à l'égard d'une tentative de paiement active ; pour la décision elle-même, vos garanties sont les droits au titre de l'Art. 22 (3) exposés ci-dessus.
9. Consentement aux cookies — accorder et retirer
La bannière cookies de uptimia.com est exploitée par Datriva (également un produit JJ Online GmbH — nous utilisons notre propre plateforme de gestion du consentement). Lorsque nous utilisons des cookies ou des technologies comparables qui nécessitent votre consentement au titre de l'Art. 6 (1)(a) RGPD et du § 25 Abs. 1 TDDDG, le mécanisme de consentement et le mécanisme de retrait sont régis par les règles suivantes.
Comment nous obtenons le consentement. Lors de votre première visite sur le site marketing, la bannière Datriva apparaît avant que tout cookie non essentiel ne soit posé. La bannière présente les trois catégories soumises à consentement (Fonctionnels, Analytiques, Marketing) en opt-in uniquement — chaque catégorie est décochée par défaut. Vous pouvez tout accepter, tout refuser ou accepter un sous-ensemble granulaire avec le même nombre de clics, conformément à l'Art. 7 (2) RGPD et aux Lignes directrices du CEPD 05/2020 sur le consentement. Les cookies strictement nécessaires sont posés sans consentement sur le fondement du § 25 Abs. 2 Nr. 2 TDDDG.
Retrait — aussi simple que d'accorder. L'Art. 7 (3) RGPD exige que le retrait du consentement soit aussi simple que de l'accorder. Conformément aux Lignes directrices du CEPD 05/2020 sur le consentement (§ 117), la parité ici signifie le même support et le même nombre d'étapes que l'opt-in original. Nous exploitons donc une voie de parité unique au titre de l'Art. 7 (3) :
- Lien Préférences des cookies dans le pied de page du site marketing (voie de parité Art. 7 (3)). Un lien « Préférences des cookies » persistant est présent dans le pied de page de chaque page marketing. Cliquer dessus rouvre la même bannière Datriva avec vos paramètres actuels, où vous pouvez désactiver n'importe quelle catégorie — ou refuser tous les cookies non essentiels — dans le même nombre de clics qu'il a fallu pour les accepter. Comme la bannière qui gère le retrait est le même élément d'UI, sur le même support, avec les mêmes contrôles de bascule que la bannière qui a géré le consentement original, le mécanisme de retrait est identique à (et pas seulement « aussi simple que ») le mécanisme d'octroi. Il s'agit de la forme la plus forte de parité Art. 7 (3) envisagée par les Lignes directrices 05/2020 sur le consentement du CEPD § 117 et c'est sur quoi nous nous appuyons comme voie de parité.
Deux autres voies sont disponibles pour votre convenance mais ne sont pas équivalentes à l'opt-in original et ne sont pas invoquées pour satisfaire à la parité de l'Art. 7 (3) :
- Courriel à privacy@uptimia.com. Nous enregistrerons et exécuterons le retrait manuellement dans le délai de l'Art. 12 (3) RGPD.
- Effacer les cookies dans votre navigateur. Ceci efface également notre enregistrement de consentement stocké localement de sorte que la bannière réapparaisse lors de votre prochaine visite ; les étapes impliquées ne sont pas équivalentes au mécanisme d'opt-in original.
Effet du retrait. Les cookies non essentiels cessent d'être posés immédiatement lors du retrait. Le retrait n'affecte pas la licéité du traitement effectué avant le retrait (Art. 7 (3) RGPD, deuxième phrase).
Pour l'inventaire par cookie, voir la Politique relative aux cookies.
10. Cookies
Nous utilisons des cookies et des technologies de suivi similaires. Notre Politique relative aux cookies expose : (i) les quatre catégories (Strictement nécessaires, Fonctionnels, Analytiques, Marketing — nous n'utilisons actuellement aucun Fonctionnel, aucun Analytique et un seul tiers de catégorie Marketing uniquement lorsque vous arrivez via ?via=), (ii) chaque cookie spécifique et entrée localStorage / sessionStorage avec son fournisseur et sa durée, (iii) les scripts tiers, (iv) les bases juridiques de chaque catégorie au titre du § 25 TDDDG et de l'Art. 6 RGPD, et (v) les mécanismes de consentement et de retrait.
11. Conservation des données
Nous ne conservons les données à caractère personnel que pour la durée nécessaire aux finalités exposées dans la présente politique ou comme requis par la loi. Conformément à l'Art. 5 (1)(e) RGPD, nous appliquons une analyse de limitation de la conservation par catégorie plutôt qu'une horloge uniforme unique. Les catégories ci-dessous couvrent l'ensemble des données à caractère personnel que nous traitons.
| Catégorie | Durée de conservation | Base juridique |
|---|---|---|
| Données de compte et d'évidence contractuelle — nom légal, courriel de contact, identité de facturation, historique des commandes et abonnements, avenants contractuels, notification de résiliation, correspondance de litige | Durée de votre compte + 3 années civiles après résiliation (ancré à la fin de l'année) | Art. 6 (1)(f) ; §§ 195 + 199 Abs. 1 BGB (constatation, exercice, défense de droits en justice) |
| Factures, registres de paiement, livres comptables | 6 à 10 ans, selon le type de document, ancrés à la fin de l'année civile — 10 ans pour les livres, inventaires et comptes annuels (§ 147 Abs. 1 Nr. 1 AO ; § 257 Abs. 1 Nr. 1, Nr. 3 HGB lu avec Abs. 4) ; 8 ans pour les pièces comptables et les registres de factures au titre du § 14b UStG (§ 147 Abs. 1 Nr. 4 et Nr. 4a AO post-Bürokratieentlastungsgesetz IV, en vigueur depuis le 1er janvier 2025 ; § 257 Abs. 4 HGB post-BEG IV) ; 6 ans pour la correspondance commerciale (§ 147 Abs. 1 Nr. 2 et Nr. 3 AO ; § 257 Abs. 1 Nr. 2 HGB) | Art. 6 (1)(c) ; § 147 AO, § 257 HGB, § 14 UStG |
| Préférences opérationnelles — préférences de notification et de communication, paramètres d'UI, filtres enregistrés, dispositions de tableau de bord, jetons d'intégration, clés API, fichiers téléversés | Durée de la relation contractuelle | Art. 6 (1)(b) |
| Événements d'authentification et d'audit de sécurité — enregistrements de connexion, événements à deux facteurs, audit IP, compteurs de tentatives échouées | 180 jours | Art. 6 (1)(f) ; référentiel BSI IT-Grundschutz |
| Score de risque heuristique indicatif interne (décrit au § 3 « Sécurité » et au § 8 « Limites de débit anti-abus et scoring de bots à l'inscription ») — un seul entier indicatif par enregistrement utilisateur | Durée de votre compte, recalculé à chaque nouveau signal d'abus et écrasé sur place (aucune table historique de scores n'est conservée) ; supprimé avec le compte lors de l'anonymisation de fin de compte au titre de la ligne « Données de compte et d'évidence contractuelle » ci-dessus | Art. 6 (1)(f) (défense anti-abus ; aucune décision Art. 22 (1) n'est prise sur la base de ce score) |
| Journaux applicatifs et d'accès — trafic routinier, journaux d'erreur | 30 jours | Art. 6 (1)(f) (intégrité opérationnelle) |
| Configurations de moniteurs que vous créez | Durée du moniteur | Art. 6 (1)(b) |
| Données de résultats de moniteurs — uptime, SSL, domaine/WHOIS, speed, transaction, agrégats RUM, virus/malware, mesures d'agent serveur | Jusqu'à 13 mois, par niveau de formule (voir la matrice par formule sur uptimia.com) | Art. 6 (1)(b) ; plafond d'utilité client |
| Corps de réponse HTTP uptime | 7 jours (expirés automatiquement) | Art. 6 (1)(b) (opérationnel uniquement) |
| Captures d'écran de transaction | 30 jours | Art. 6 (1)(f) ; minimisation des données au titre de l'Art. 5 (1)(c) (des données à caractère personnel peuvent être visibles sur les écrans authentifiés) |
| Correspondance de support | Durée du dossier de support + 3 années civiles (ancrées à la fin de l'année) | Art. 6 (1)(f) ; §§ 195 + 199 BGB |
| Enregistrements de consentement aux cookies | 180 jours pour l'enregistrement du consentement + 12 mois de conservation du journal d'audit | Art. 7 (1) RGPD (preuve du consentement) |
| Sauvegardes | Fenêtre glissante de 14 jours | Art. 6 (1)(f) (reprise après sinistre) |
Une fois la période ci-dessus expirée, les données à caractère personnel sont supprimées ou — lorsque la suppression compromettrait l'intégrité d'audit — anonymisées de sorte que la ré-identification ne soit plus raisonnablement possible. La conservation statutaire (la deuxième ligne ci-dessus) prévaut sur la suppression antérieure au titre de l'Art. 17 (3)(b) RGPD.
Comportement à l'effacement du compte (Art. 17 RGPD). Lorsque vous supprimez votre compte via les Paramètres ou par demande à privacy@uptimia.com, les intégrations de paiement, les pages d'état, les opérateurs et les sessions actives sont supprimés immédiatement ; les configurations de moniteurs et les paramètres d'alerte entrent dans la queue de défense des réclamations décrite dans la première ligne ci-dessus ; votre identité de contact et d'évidence contractuelle est anonymisée ou supprimée à la fin de cette queue, sous réserve de la conservation statutaire requise pour les factures et les livres comptables. Les sauvegardes vieillissent selon la fenêtre glissante de 14 jours : pendant cette fenêtre, les données ne sont pas activement traitées et n'existent que sous forme d'instantané gelé de reprise après sinistre. La combinaison d'une fenêtre glissante courte, de l'absence de traitement actif pendant cette fenêtre et de l'étape de ré-effacement-sur-restauration décrite ci-dessous est conforme à la pratique des autorités de contrôle établie en matière de sauvegardes au titre de l'Art. 17 (1) / (3) RGPD. Nous tenons un registre interne des sauvegardes documentant les systèmes dans le champ (base de données applicative, base de données séries temporelles, AWS S3 Francfort pour les captures d'écran de transaction), la politique de rotation, le lieu de stockage, les contrôles d'accès et le runbook de ré-effacement. Si nous restaurons à partir d'une sauvegarde antérieure à une demande d'effacement, l'effacement original est ré-appliqué aux données restaurées dans les 72 heures suivant l'achèvement de la restauration — et, lorsque la restauration ramène le système en ligne pour un traitement actif, avant que le système restauré ne soit ouvert au trafic utilisateur — afin que les données à caractère personnel effacées ne soient pas réintroduites dans le traitement actif. Le plafond de 72 heures est l'engagement d'audit externe ; en fonctionnement normal, la rejoue de ré-effacement s'exécute comme première étape scriptée après la restauration et se termine en minutes, non en heures. Le registre des sauvegardes enregistre, pour chaque restauration de production, (i) l'horodatage d'achèvement de la restauration, (ii) l'horodatage d'achèvement de la rejoue du journal d'effacement, et (iii) la confirmation qu'aucun trafic utilisateur n'a été admis dans le système restauré entre (i) et (ii).
Données de visiteur traitées au titre du § 7 (rôle de sous-traitant). Conservées conformément au DPA, généralement selon vos instructions en qualité de responsable du traitement. Les valeurs par défaut correspondent à la catégorie équivalente ci-dessus.
Conversations de support hébergées par HelpCanvas. HelpCanvas est un produit JJ Online tournant sur l'infrastructure UE propre de JJ Online (§ 5.7) — non une plateforme tierce — de sorte que JJ Online est le responsable unique de la conversation indépendamment de la surface depuis laquelle elle est lue ou écrite. La conservation suit la ligne Correspondance de support ci-dessus (durée du dossier de support + 3 années civiles ancrées à la fin de l'année ; Art. 6 (1)(f) ; §§ 195 + 199 BGB). Il n'y a pas de conservation « plateforme-source » distincte à laquelle déférer.
12. Sécurité des données
Nous mettons en œuvre des mesures techniques et organisationnelles appropriées au titre de l'Art. 32 RGPD pour protéger vos données à caractère personnel contre tout accès, divulgation, altération ou destruction non autorisés. En pratique :
- TLS 1.2+ pour toutes les interfaces orientées client et toutes les communications avec les sous-traitants ultérieurs
- Contrôles d'accès fondés sur les rôles limitant l'accès aux données à caractère personnel au personnel qui en a besoin ; authentification multi-facteurs pour tout le personnel opérationnel
- Obligations écrites de confidentialité du personnel
- Chiffrement disque au repos pour la base de données applicative et la base de données séries temporelles sur l'infrastructure UE ; sauvegardes chiffrées sous une clé gérée séparément
- Chiffrement (enveloppe) au niveau colonne pour les identifiants et secrets que vous fournissez pour que le Service agisse en votre nom — voir le paragraphe dédié ci-dessous ; les clés API personnelles sont stockées sous forme de hachages unidirectionnels uniquement
- Troncature de l'adresse IP pour les événements RUM (
/24IPv4,/48IPv6) avant stockage - Isolation logique par utilisateur dans la couche applicative
- Processus de notification de violation de données à caractère personnel à 72 heures conformément à l'Art. 33 RGPD
- Scans de vulnérabilités périodiques, monitoring des dépendances, revue de code avant fusion
Identifiants et secrets que vous nous confiez. Lorsque vous fournissez des identifiants pour que le Service puisse s'authentifier à vos ressources en votre nom — par exemple, identifiants HTTP Basic, en-têtes de requête personnalisés (y compris jetons bearer et clés API), identifiants d'intégration pour les canaux d'alerte, et valeurs littérales configurées dans les étapes de monitoring transactionnel — ces identifiants sont conservés sous chiffrement au niveau colonne en plus du chiffrement disque qui s'applique à la base de données dans son ensemble. Les clés de chiffrement sont gérées séparément de la base de données elle-même, de sorte que le personnel opérationnel ayant accès à la base de données ne peut pas lire les identifiants en clair. Le déchiffrement n'intervient qu'au point où le réseau de sondes exécute le contrôle contre la ressource que vous avez configurée, et le clair n'est tenu en mémoire que pour la durée de cette unique exécution de contrôle. Les clés API personnelles que vous créez pour un accès programmatique au Service sont stockées sous forme de hachages unidirectionnels ; nous ne conservons pas de copie en clair après émission — si vous perdez une clé API personnelle, vous devez la rotater via le tableau de bord.
Aucune méthode de transmission par internet ou de stockage électronique n'est totalement sécurisée. Si vous pensez que votre interaction avec nous n'est plus sécurisée, contactez privacy@uptimia.com.
13. Vos droits
En tant que responsable du traitement établi dans l'Union européenne, nous sommes soumis au RGPD au titre de l'Art. 3 (1) pour l'ensemble de nos traitements, indépendamment du lieu où se trouve la personne concernée. Les droits ci-dessous s'appliquent donc à toute personne dont nous traitons les données à caractère personnel, et non seulement aux résidents UE/EEE/Royaume-Uni/Suisse.
Vous disposez des droits suivants :
- Droit d'accès (Art. 15 RGPD) — demander une copie des données à caractère personnel que nous détenons à votre sujet
- Droit de rectification (Art. 16 RGPD) — demander la correction de données inexactes ou incomplètes
- Droit à l'effacement (Art. 17 RGPD) — demander la suppression, sous réserve des exceptions de l'Art. 17 (3) (en particulier : obligation légale au titre du § 147 AO / § 257 HGB pour les factures)
- Droit à la limitation du traitement (Art. 18 RGPD)
- Droit à la portabilité des données (Art. 20 RGPD) — recevoir vos données dans un format structuré, couramment utilisé et lisible par machine
- Droit d'opposition (Art. 21 RGPD) — vous opposer au traitement fondé sur nos intérêts légitimes, y compris au profilage ; l'opposition à la prospection directe est inconditionnelle
- Droit de ne pas faire l'objet d'une décision automatisée (Art. 22 RGPD) — une décision Art. 22 (1) existe au check-out (filtrage anti-fraude au paiement) ; le traitement sous-jacent repose principalement sur l'Art. 6 (1)(c) RGPD (conformité statutaire SCA DSP2 + AML/CFT) avec l'Art. 6 (1)(f) couvrant l'intérêt résiduel de prévention de la fraude côté commerçant, et la décision Art. 22 (1) elle-même est autorisée par la passerelle de droit habilitant de l'Union au titre de l'Art. 22 (2)(b) RGPD (avec l'Art. 22 (2)(a) traité comme repli uniquement). Nous fournissons les garanties de l'Art. 22 (3) (intervention humaine, expression du point de vue, contestation, plus la divulgation du code de motif de refus et du nom de règle Stripe Radar décrite au § 8). Toutes les autres activités automatisées du § 8 sont du profilage sans décision exclusivement automatisée à effet significatif attachée. Détails au § 8.
- Droit de retirer le consentement (Art. 7 (3) RGPD) — lorsque nous nous appuyons sur votre consentement, retirer à tout moment sans affecter la licéité du traitement antérieur
- Droit d'introduire une réclamation auprès d'une autorité de contrôle (Art. 77 RGPD) — l'Art. 77 (1) vous offre trois forums alternatifs : l'autorité de contrôle de (i) votre résidence habituelle, (ii) votre lieu de travail ou (iii) le lieu de l'infraction alléguée. Voir § 15 ci-dessous pour les autorités compétentes et le répertoire des autorités de contrôle de l'EEE.
Pour exercer l'un quelconque de ces droits, contactez privacy@uptimia.com. Au titre de l'Art. 12 (3) RGPD, nous répondrons dans un délai d'un mois à compter de la réception d'une demande complète, prorogeable de deux mois supplémentaires pour les demandes complexes ou nombreuses ; en cas de prolongation, nous vous informons de la prolongation et de la raison dans le premier mois, comme l'Art. 12 (3) l'exige.
Voies opérationnelles d'exécution.
- Droit d'accès (Art. 15 RGPD) et droit à la portabilité des données (Art. 20 RGPD) — export des données du compte. Tant que le libre-service n'est pas disponible, l'export est généré et retourné manuellement sur demande par courriel à privacy@uptimia.com. En interne, nous tenons une procédure opératoire standardisée écrite de SAR (Demande d'accès de la personne concernée) qui vise un délai de livraison opérationnel de cinq (5) à dix (10) jours ouvrés pour un compte normal, bien dans le plafond statutaire d'un mois de l'Art. 12 (3). L'export est livré sous forme d'une archive ZIP unique contenant des fichiers JSON structurés par catégorie de données — profil de compte, historique de facturation, configurations de moniteurs (identifiants montrés en empreintes unidirectionnelles, jamais en clair ; voir § 12), résumés de résultats de contrôles, index de correspondance de support, enregistrement de consentement aux cookies — via un lien de téléchargement à durée limitée. Un point de terminaison libre-service
/api/v1/me/exportfigure sur la feuille de route produit ; tant qu'il n'est pas livré, la SOP manuelle est la garantie opérationnelle. - Droit à l'effacement (Art. 17 RGPD). La suppression du compte est en libre-service depuis la page Paramètres (confirmée par mot de passe) et déclenche le cron de purge décrit au § 11 ; les registres fiscaux et comptables survivent conformément au § 11 / § 147 AO / § 257 HGB. Lorsque vous préférez un traitement humain, écrivez à privacy@uptimia.com.
- Droit de rectification (Art. 16 RGPD). La plupart des champs du compte sont éditables par l'utilisateur dans la page Paramètres ; pour les champs qui ne sont pas éditables par l'utilisateur (par ex. nom de facturation sur des documents fiscaux déjà émis), envoyez un courriel à privacy@uptimia.com.
- Droit à la limitation (Art. 18 RGPD) et droit d'opposition (Art. 21 RGPD). Envoyez un courriel à privacy@uptimia.com en identifiant le traitement que vous souhaitez restreindre ou auquel vous souhaitez vous opposer. L'opposition à la prospection directe est traitée dès réception sans motivation supplémentaire (Art. 21 (2) et (3) RGPD).
- Droit de retirer le consentement (Art. 7 (3) RGPD). Pour les cookies, voir § 9 (lien Préférences des cookies, voie de parité unique conforme aux Lignes directrices 05/2020 du CEPD § 117). Pour tout autre traitement fondé sur le consentement, envoyez un courriel à privacy@uptimia.com.
Toutes les demandes sont traitées gratuitement. Lorsqu'une demande est manifestement non fondée ou excessive, nous pouvons facturer des frais administratifs raisonnables ou refuser d'agir au titre de l'Art. 12 (5) RGPD.
Vérification de l'identité. Notre approche de vérification d'identité est proportionnée à la demande, comme l'exigent l'Art. 12 (6) RGPD et les Lignes directrices 01/2022 du CEPD sur les droits de la personne concernée — Droit d'accès (§ 64 et s.). Dans le cas normal, nous vérifions l'identité en faisant correspondre l'adresse d'expédition de votre demande à l'adresse électronique enregistrée pour votre compte Uptimia, et, pour les actions entreprises depuis l'intérieur de l'application, en nous appuyant sur votre session authentifiée (mot de passe + 2FA lorsque vous l'avez activée). Lorsque cette correspondance suffit à lever le doute raisonnable, nous ne demandons pas d'informations complémentaires — demander une pièce d'identité à chaque demande routinière violerait elle-même le principe de minimisation des données de l'Art. 5 (1)(c) RGPD. Lorsque nous avons un doute raisonnable spécifique au titre de l'Art. 12 (6) RGPD — par exemple, lorsque la demande émane d'une adresse autre que celle enregistrée, lorsque le compte a récemment changé de mains ou vu son courriel de contact mis à jour, lorsque la demande concerne des catégories sensibles telles que les journaux d'authentification ou les signaux de fraude au paiement, ou lorsque l'action demandée est irréversible (export complet de données, effacement du compte) — nous pouvons appliquer une ou plusieurs vérifications supplémentaires proportionnées : confirmation depuis l'adresse électronique enregistrée, accomplissement d'une action depuis le tableau de bord authentifié ou un code à usage unique délivré via votre canal 2FA configuré. Nous ne demandons pas de pièce d'identité émise par l'État, ni de copie de documents d'identité, ni de vérification par « selfie » — ces mesures seraient disproportionnées pour un produit d'observabilité B2B dont le rattachement de compte est à une adresse électronique, non à une identité du monde réel, et elles sont incohérentes avec la mise en garde des Lignes directrices 01/2022 du CEPD § 73 contre la collecte routinière de pièces d'identité. Si, après des vérifications proportionnées, un doute raisonnable sur votre identité subsiste, nous demanderons, conformément à l'Art. 12 (6) RGPD, le minimum d'informations supplémentaires strictement nécessaires pour lever ce doute, et nous vous dirons exactement ce que nous demandons et pourquoi.
14. Vie privée des enfants
Le Service n'est pas destiné aux enfants de moins de 16 ans, et nous ne collectons pas sciemment de données à caractère personnel auprès d'enfants de moins de 16 ans. Si nous apprenons avoir collecté des données à caractère personnel d'un enfant de moins de 16 ans sans consentement parental vérifiable, nous les supprimerons dès que possible.
Nous appliquons 16 ans comme plancher global pour le traitement fondé sur le consentement, indépendamment de tout seuil national inférieur au titre de l'Art. 8 (1) RGPD — et nous sommes conscients que plusieurs États membres ont exercé le Wahlrecht de l'Art. 8 (1) à la baisse, notamment l'Espagne à 14 ans, la France à 15 ans et l'Italie à 14 ans. Le plancher « 16 globalement » est donc une norme délibérée et auto-imposée plus protectrice que les seuils nationaux applicables les plus bas dans ces marchés, et nous acceptons d'être auditables sur ce point en tant que politique : si nous commençons un jour à cibler directement l'un de ces marchés à seuil inférieur, nous continuerons à appliquer le plancher de 16 ans plutôt que de descendre au minimum national, et tout changement de cette position serait lui-même une modification matérielle de la présente Politique divulguée au titre du § 17. Notre approche de vérification est proportionnée à un service qui n'est pas destiné aux enfants, au sens envisagé par l'Art. 8 (2) RGPD. Nous ne collectons pas de date de naissance à l'inscription — Uptimia est un produit d'observabilité B2B, la surface d'inscription est orientée administrateur technique (noms de serveurs, URL de moniteurs, canaux d'alerte), et demander une date de naissance à chaque titulaire de compte créerait elle-même un problème de minimisation des données disproportionné au risque. Nous nous appuyons plutôt sur la combinaison de : (i) le Service n'est pas destiné aux enfants, ni commercialisé auprès des enfants, ni conçu pour les enfants ; (ii) les titulaires de compte s'auto-identifient comme utilisateurs professionnels par l'acte de configurer des moniteurs, d'accepter des abonnements payants ou de signer les Conditions générales d'utilisation ; (iii) lorsque, sur le fond d'un compte ou d'une interaction de support, nous avons un doute raisonnable qu'un titulaire de compte soit âgé de moins de 16 ans — par exemple, une correspondance de support indiquant affirmativement que le compte est exploité par un mineur — nous demandons au titulaire de compte de confirmer par écrit qu'il a 16 ans ou plus, et supprimons le compte en l'absence de confirmation. C'est le modèle « service non destiné aux enfants, avec suppression sur doute raisonnable » que la formulation de proportionnalité de l'Art. 8 (2) RGPD envisage pour les services B2B.
Lorsque vous déployez notre script RUM sur un site web destiné aux enfants, il s'agit de votre propre décision au titre de l'Art. 8 RGPD et de votre propre responsabilité de responsable du traitement.
Les parents ou tuteurs qui pensent qu'un enfant a soumis des données à caractère personnel peuvent contacter privacy@uptimia.com pour une suppression immédiate.
15. Régimes applicables, autorité de contrôle chef de file et transferts transfrontaliers
Régimes applicables
- RGPD UE. En tant que responsable du traitement établi en Allemagne, le Règlement (UE) 2016/679 s'applique au titre de l'Art. 3 (1) à tous nos traitements indépendamment du lieu où se trouve la personne concernée.
- UK GDPR. Nous ne dirigeons pas notre Service vers des personnes concernées au Royaume-Uni. L'analyse du champ territorial des Lignes directrices 3/2018 du CEPD § 2.1 / § 2.2 repose sur une lecture cumulative des marqueurs cités — monnaie, domaine de premier niveau, langue comme signal-pays, mention de clients locaux, campagnes marketing pays-spécifiques, téléphone ou adresse locale dédiés, conditions de livraison — et la conclusion est atteinte en examinant les marqueurs ensemble, non en écartant un marqueur particulier. Selon une lecture cumulative de ces facteurs, aucun ne pointe vers le Royaume-Uni : nos prix sont listés en EUR (et, le cas échéant, en USD), non en GBP ; notre domaine est uptimia.com sans surface en
.co.uk; nous ne publions aucune page d'atterrissage UK, aucune étude de cas UK, aucun témoignage client résident UK, aucune campagne marketing UK-spécifique, et aucune publicité géo-ciblée UK ; nous n'opérons aucun référencement en langue UK ou aucune production de contenu ciblée UK ; et le Site est publié en anglais parce que l'anglais est la langue contrôlante de notre documentation et de notre produit (l'anglais n'est pas, selon l'analyse des Lignes directrices 3/2018, un signal-pays lorsqu'il n'est pas associé à l'un des autres marqueurs ci-dessus). Sur ces faits, nous considérons que l'Art. 3 (2)(a) UK GDPR n'est pas engagé : les personnes concernées UK qui s'inscrivent au Service le font en atteignant uptimia.com par recherche organique en anglais et non parce que nous le leur avons offert au Royaume-Uni au sens de l'Art. 3 (2)(a). Nous ne « surveillons pas le comportement » des personnes concernées UK au sens de l'Art. 3 (2)(b) non plus — le script RUM que le Responsable déploie tourne sur les propres visiteurs du Responsable sur les propres sites web du Responsable et est traité sur les instructions du Responsable, non dirigé par nous vers une population UK. Si l'Art. 3 (2) UK GDPR devait néanmoins être considéré comme s'appliquant à des inscriptions UK incidentes, notre traitement satisfait également à l'exemption de l'Art. 27 (2)(a) UK GDPR comme occasionnel (pas d'opérations UK structurées, pas d'activité d'acquisition UK, pas de motion de réussite client UK) et à faible risque (pas de données de catégorie particulière, pas de profilage à grande échelle, pas de monitoring à grande échelle de personnes concernées UK). Nous réévaluerons cette position et nommerons un représentant UK si nous commençons à cibler le Royaume-Uni — par exemple en ajoutant un prix en GBP, un domaine ou sous-répertoire.co.uk, des études de cas ou témoignages UK, des pages d'atterrissage ou de comparaison UK-spécifiques, une acquisition payante géo-ciblée UK, ou une production de contenu en langue UK. Les personnes concernées UK qui interagissent avec le Service conservent leur droit statutaire d'introduire une réclamation auprès de l'Information Commissioner's Office (ICO) à https://ico.org.uk au titre de l'Art. 77 UK GDPR ; nous coopérerons avec toute enquête de l'ICO sur le fond, indépendamment de notre position en matière de champ territorial. - Autres juridictions (CCPA / CPRA, LGPD, PIPL et régimes extraterritoriaux similaires). Nous ne traitons pas actuellement de données à caractère personnel de consommateurs californiens, de personnes concernées brésiliennes, de personnes concernées chinoises ou d'autres personnes concernées hors EEE / hors Royaume-Uni / hors Suisse à une échelle ou dans une configuration qui déclenche les seuils d'application extraterritoriale du California Consumer Privacy Act (tel que modifié par le California Privacy Rights Act), de la Loi générale brésilienne de protection des données (LGPD), de la Loi chinoise sur la protection des informations personnelles (PIPL) ou de régimes de confidentialité hors UE comparables. En particulier, nous sommes en dessous des seuils de revenu US et de consommateurs californiens pour l'applicabilité du CCPA / CPRA au titre du Cal. Civ. Code § 1798.140(d). Nous surveillons notre exposition au titre de chacun de ces régimes à mesure que notre base client évolue et mettrons à jour la présente Politique et nommerons des représentants locaux ou des agents désignés (par ex., un agent US de demandes vérifiées au titre du § 999.312 des règlements CCPA ; un encarregado (DPO) au titre de l'Art. 41 LGPD — étant noté que la LGPD elle-même ne contient pas d'équivalent à l'Art. 27 RGPD et que toute obligation de représentation locale au Brésil surgirait séparément en droit des sociétés brésilien (en particulier l'Art. 1.134 du Code civil brésilien et l'Art. 146 § 2 de la Loi 6.404/1976), non au titre de la LGPD en tant que telle ; un représentant local PIPL au titre de l'Art. 53 PIPL) si et lorsque les seuils sont franchis.
- LPD suisse. S'applique au titre de l'Art. 3 (1) LPD lorsque nos activités produisent un effet en Suisse. L'analyse de ciblage ici reflète la discipline de lecture cumulative appliquée ci-dessus pour le Royaume-Uni : la question est de savoir si les facteurs marqueurs-pays cités, pris ensemble, pointent vers la Suisse — non si chaque facteur individuel peut être écarté isolément. Sur une lecture cumulative, aucun ne le fait : nous n'exploitons aucun domaine
.ch, aucun prix en CHF, aucune page d'atterrissage suisse et aucune campagne ciblée Suisse ; et le Site est publié en anglais, non comme signal-pays suisse mais comme notre langue de documentation contrôlante. L'Art. 14 al. 1 LPD exige d'un responsable privé domicilié à l'étranger qu'il désigne un représentant en Suisse lorsqu'il traite des données à caractère personnel de personnes en Suisse et que le traitement satisfait cumulativement à quatre conditions : (a) le traitement est en lien avec l'offre de biens ou de services ou avec la surveillance du comportement de ces personnes ; (b) il est étendu (à grande échelle) ; (c) il est régulier ; et (d) il pose un risque élevé pour la personnalité des personnes concernées (hohes Risiko für die Persönlichkeit der betroffenen Personen). Le seuil n'est pas atteint sur nos faits : les personnes concernées suisses qui s'inscrivent au Service atteignent uptimia.com par recherche organique en anglais incidentellement à nos opérations UE, non par une offre suisse de notre part — de sorte que la condition (a) n'est pas engagée — et le volume n'est ni étendu au sens de la condition (b) ni régulier au sens de la condition (c) tels que ces termes sont compris dans les orientations du PFPDT ; nous considérons également que la condition (d) n'est pas remplie, puisque le Service ne pose pas, sur les faits de notre traitement incident suisse typique, un risque élevé pour la personnalité des personnes concernées. La défaillance de l'une quelconque des quatre conditions cumulatives suffit à elle seule ; sur nos faits, les conditions (a)-(d) échouent indépendamment chacune. (Notez que risque élevé est à la fois la condition d'appointement de représentant de l'Art. 14 al. 1 (d) ci-dessus et, séparément, le déclencheur d'une analyse d'impact relative à la protection des données au titre de l'Art. 22 LPD — ce sont des obligations indépendantes attachées au même élément factuel, et nous traitons l'analyse d'AIPD au titre de l'Art. 22 LPD séparément.) Nous réévaluerons et nommerons un représentant suisse si nous commençons à cibler la Suisse (une surface.ch, des prix en CHF, des études de cas suisses, de la publicité ciblée Suisse) ou si notre traitement suisse devient à grande échelle et régulier.
Autorité de contrôle chef de file
Notre autorité de contrôle chef de file au titre du mécanisme de guichet unique du RGPD est la Berliner Beauftragte für Datenschutz und Informationsfreiheit (BlnBDI) :
Alt-Moabit 59-61 10555 Berlin, Allemagne Site web : https://www.datenschutz-berlin.de
Les résidents de l'EEE peuvent porter plainte, à leur choix au titre de l'Art. 77 (1) RGPD, auprès de l'autorité de contrôle de (i) leur résidence habituelle, (ii) leur lieu de travail ou (iii) le lieu de l'infraction alléguée — ou auprès de la BlnBDI directement en tant qu'autorité chef de file. Le répertoire des autorités de contrôle de l'EEE figure à https://edpb.europa.eu. Les résidents UK peuvent porter plainte auprès de l'Information Commissioner's Office (ICO) à ico.org.uk au titre de l'Art. 77 UK GDPR. Les résidents suisses peuvent notifier le Préposé fédéral à la protection des données et à la transparence (PFPDT / EDÖB) à edoeb.admin.ch au titre de l'Art. 49 LPD.
Résumé de l'analyse des intérêts légitimes
Pour chaque finalité fondée sur l'Art. 6 (1)(f) :
- Signaux de sécurité du compte (votre IP d'inscription, votre IP de connexion la plus récente, votre compteur de tentatives échouées, votre journal d'audit de l'authentification à deux facteurs et un score de risque heuristique interne) — notre intérêt à protéger votre compte contre le credential stuffing, les attaques par force brute et l'abus à l'inscription, mis en balance avec la nature limitée et liée au compte des signaux ; les intérêts de la personne concernée sont protégés par les contrôles d'accès et le fait que les données sont liées à une relation contractuelle.
- Amélioration du service et opérations du réseau de sondes — traitement pseudonymisé ou agrégé uniquement ; pas de profilage individuel.
- Surveillance agrégée de la qualité des mesures côté serveur — pas d'identification individuelle.
- Communications de mise à jour produit aux titulaires de compte existants (§ 7 Abs. 3 UWG Bestandskundenwerbung) — notre intérêt à retenir les clients payants en les tenant informés des modifications produit qui affectent ce qu'ils ont acheté, mis en balance avec l'imposition d'une charge marketing sur le destinataire. Le respect des quatre conditions cumulatives du § 7 Abs. 3 UWG est traité comme la garantie principale : (i) adresse collectée dans le cadre de la vente de nos biens ou services ; (ii) contenu limité à la prospection directe de nos propres produits et services similaires ; (iii) le destinataire ne s'est pas opposé ; et (iv) le destinataire a été clairement et de manière apparente informé (klar und deutlich) du droit d'opposition tant au point de collecte que dans chaque message ultérieur, sans coûts au-delà des tarifs de transmission de base (Basistarif). L'opposition au titre de l'Art. 21 RGPD est inconditionnelle et traitée dès réception sans motivation supplémentaire.
- Réponses aux demandes hors client — répondre aux demandes entrantes de visiteurs qui nous contactent (questions commerciales, demandes de partenariat, questions de support hors compte actif) est fondé sur l'attente raisonnable que nous répondrons à l'adresse qu'ils ont utilisée pour nous écrire.
Une AIL complète pour l'une quelconque de ces activités est disponible sur demande à privacy@uptimia.com.
Prise de décision automatisée (Art. 22 RGPD)
Une décision automatisée dans le champ de l'Art. 22 (1) RGPD opère au point du filtrage anti-fraude au paiement au check-out, décrite au § 8. La passerelle de l'Art. 22 (2) sur laquelle nous nous appuyons est principalement l'Art. 22 (2)(b) RGPD — le cadre SCA de la DSP2 (Directive (UE) 2015/2366 lue avec le Règlement délégué (UE) 2018/389 de la Commission) et le cadre AML/CFT cité au § 8 constituent un droit de l'Union habilitant qui requiert les décisions de surveillance des transactions prises au check-out et qui prévoit lui-même des garanties appropriées pour la personne concernée ; l'Art. 22 (2)(a) RGPD (nécessité contractuelle) est engagé comme repli uniquement, en accord avec la lecture étroite du CEPD de « nécessaire à l'exécution du contrat ». Nous fournissons les garanties de l'Art. 22 (3) RGPD dans leur intégralité : un droit significatif à l'intervention humaine par l'équipe d'examen manuel du prestataire de paiement et par nos opérations de facturation, un droit d'exprimer votre point de vue, un droit de contester le résultat et — ajouté le 27 mai 2026 — la divulgation sur demande au titre de l'Art. 22 (3) du code de motif de refus spécifique et, le cas échéant, du nom de la règle Stripe Radar (voir § 8 quatrième puce de l'Art. 22 (3)). Le contact pour toute demande de ce type est privacy@uptimia.com ; nous répondons dans le délai de l'Art. 12 (3) RGPD. Le score heuristique interne dans votre enregistrement utilisateur décrit au § 8 est une entrée indicative à l'examen humain, non une décision automatisée.
Notification de violation de données à caractère personnel (Art. 33-34 RGPD)
En cas de violation de données à caractère personnel susceptible d'engendrer un risque pour vos droits et libertés, nous notifierons la BlnBDI sans retard injustifié et, lorsque cela est possible, dans les 72 heures suivant la connaissance de la violation (Art. 33 RGPD). Lorsque la violation est susceptible d'engendrer un risque élevé, nous notifierons également les utilisateurs concernés sans retard injustifié au titre de l'Art. 34 RGPD.
Mécanisme de notification. Courriel direct à l'adresse enregistrée sur votre compte, avec une ligne d'objet identifiant le message comme notification de violation de données à caractère personnel au titre de l'Art. 34 RGPD. Nous affichons en outre un avis in-product dans le tableau de bord authentifié lors de votre prochaine session. Lorsque la notification directe impliquerait un effort disproportionné au titre de l'Art. 34 (3)(c), nous émettons une communication publique sur le Site.
Transferts internationaux de données
Nous transférons des données à caractère personnel à des destinataires hors EEE uniquement dans le cadre de l'exploitation normale des services tiers listés aux § 5 et § 7. Les destinations hors EEE suivantes sont concernées :
| Destination | Destinataire(s) | Mécanisme |
|---|---|---|
| États-Unis | Stripe, Inc. (sous-traitance ultérieure Stripe) ; PayPal, Inc. (sous-traitance ultérieure PayPal) ; Amazon Web Services, Inc. (SES destinataires hors UE, réseau de sondes régions hors UE) ; DigitalOcean, LLC (réseau de sondes) ; Akamai Technologies, Inc. (réseau de sondes) ; Vultr Holdings, LLC (réseau de sondes) ; Contabo GmbH (réseau de sondes — régions de sondes situées aux US ; l'entité contractante est Contabo GmbH à Munich, le traitement physique a lieu sur l'infrastructure US de Contabo) ; Okta, Inc. (sous-traitance ultérieure Auth0) ; GitHub, Inc. (connexion sociale Auth0) ; Google LLC (sous-traitance ultérieure Web Risk, PageSpeed ; connexion sociale Auth0) ; Mattermost, Inc. (alertes, si configuré) ; PagerDuty, Inc. (alertes, si configuré) ; Microsoft Corporation (sous-traitance ultérieure alertes Teams, si configuré) ; Slack Technologies, LLC (groupe Salesforce) (sous-traitance ultérieure alertes Slack, si configuré) ; Discord, Inc. (sous-traitance ultérieure alertes Discord, si configuré) ; X Corp. (alertes X, si configuré) ; Twilio, Inc. (sous-traitance ultérieure SMS) ; Meta Platforms, Inc. (sous-traitance ultérieure WhatsApp Cloud) | Data Privacy Framework UE-US (Décision d'exécution (UE) 2023/1795) lorsque le destinataire est certifié DPF, avec les CCT (Décision d'exécution (UE) 2021/914) maintenues comme repli automatique. Vultr n'est pas certifié DPF — les CCT + la propriété de traitement éphémère sur la couche sonde (voir § 5.3) sont les mesures supplémentaires invoquées. Contabo est contracté via son entité UE (Contabo GmbH, Munich) de sorte que l'analyse CCT s'applique au volet de traitement physique aux régions Contabo hors UE ; la même propriété de traitement éphémère sur la couche sonde (Annexe B.6 du DPA) est la mesure supplémentaire invoquée pour les régions Contabo hors UE. X Corp. n'est pas actuellement certifié DPF — CCT + mesures supplémentaires ; activé seulement si vous configurez X comme canal d'alerte. |
| Émirats arabes unis | Telegram FZ-LLC (alertes, seulement si vous configurez Telegram) | Aucune décision d'adéquation pour les EAU, et Telegram FZ-LLC n'offre pas de mécanisme de transfert standard au titre de l'Art. 46 RGPD (pas d'offre de CCT publiée, pas de modèle de DPA, pas de matériels d'évaluation d'impact des transferts). Nous nous appuyons donc, en qualité de responsable initiant le transfert lorsqu'une alerte est dispatchée, sur la dérogation de l'Art. 49 (1)(b) RGPD — le transfert est nécessaire à l'exécution du contrat entre vous (le titulaire du compte, en qualité de personne concernée) et Uptimia : en configurant Telegram comme votre canal de livraison d'alerte choisi dans les paramètres de canaux d'alerte, vous avez fait de la livraison de l'alerte à votre chat Telegram un élément objectivement nécessaire du service de monitoring que vous avez contracté. La base de l'Art. 49 (1)(b) couvre les propres données à caractère personnel du titulaire du compte (votre identifiant Telegram, l'identifiant du canal du bot que vous avez fourni, la charge utile de l'alerte qui vous est adressée). Lorsque vous routeriez des alertes vers un groupe ou un canal Telegram qui inclut des destinataires qui ne sont pas parties à votre contrat Uptimia, ces destinataires sont hors du champ de la base de l'Art. 49 (1)(b) — veuillez utiliser un arrangement responsable-à-responsable de votre propre fait (par ex. obtenir le consentement explicite de l'Art. 49 (1)(a) de ces destinataires avant de les ajouter, ou router l'alerte via un intermédiaire avec lequel ils ont une relation établie), et ne vous appuyez pas sur la couverture Art. 49 (1)(b) d'Uptimia pour ce volet. Les mesures supplémentaires que nous appliquons de notre côté sont le chiffrement en transit (HTTPS vers l'API Bot Telegram), la minimisation de la charge utile (l'événement d'alerte contient uniquement des métadonnées d'incident — nom du moniteur, changement d'état, horodatage ; nous ne transmettons pas de données à caractère personnel d'utilisateurs finaux de vos visiteurs), et le canal est opt-in (configurable en marche, configurable à l'arrêt). Conformément aux Lignes directrices 2/2018 du CEPD sur les dérogations au titre de l'Article 49 § III, nous traitons l'invocation de l'Art. 49 (1)(b) comme occasionnelle et nécessaire : elle n'est engagée que sur les comptes qui ont affirmativement configuré Telegram, les données transférées sont minimisées à ce qui est strictement requis pour la livraison de l'alerte, et nous reconsidérerons la base si les alertes Telegram deviennent un flux structurellement répétitif pour un compte donné au-delà de ce qui est requis pour exécuter votre contrat. Recommandé pour la mise en astreinte de l'équipe ops uniquement ; ne scriptez pas de données à caractère personnel d'utilisateurs finaux dans les charges utiles d'alerte Telegram. |
| Australie (avec traitement en aval aux États-Unis) | Atlassian Pty Ltd (alertes Statuspage et pages d'état publiques, seulement si vous configurez Statuspage comme canal d'alerte ou surface de page d'état) | Aucune décision d'adéquation pour l'Australie. Statuspage est exploité par Atlassian sur l'infrastructure US (AWS), de sorte qu'un transfert vers les États-Unis surgit en parallèle avec le transfert vers la partie contractante en Australie. Nous nous appuyons sur l'Addendum au traitement de données publié d'Atlassian et sur les CCT UE (Décision d'exécution (UE) 2021/914) couvrant les flux responsable-australien et sous-traitant-ultérieur-US, ensemble avec la liste des Sous-traitants ultérieurs d'Atlassian (que nous surveillons à chaque révision de politique) pour la chaîne en aval. Mesures supplémentaires : TLS 1.2+ sur chaque alerte / événement de page d'état sortant, minimisation de la charge utile d'alerte / page d'état à des métadonnées d'incident (une alerte ou un post de statut est état d'incident, chronologie et résumé ; aucune donnée à caractère personnel d'utilisateur final n'est requise dans un événement Statuspage), et le canal / surface de page d'état est activé seulement sur votre configuration. Vous portez l'évaluation des risques côté responsable du choix de Statuspage comme canal d'alerte ou surface d'état publique. |
Pour le régime UK GDPR parallèle, nous appliquons l'International Data Transfer Agreement UK et l'Addendum UK aux CCT UE (ICO mars 2022) pour les clients UK incidents. Pour le régime LPD suisse, nous appliquons les CCT UE approuvées par le PFPDT avec l'addendum spécifique suisse.
Une Évaluation d'Impact de Transfert par destinataire est tenue à jour pour chaque destinataire US et pour la ligne Atlassian (Australie + US en aval). Copies disponibles à privacy@uptimia.com. La ligne Telegram (EAU) ne repose pas sur l'Art. 46 RGPD — elle repose au contraire sur la dérogation de l'Art. 49 (1)(b) RGPD, avec le périmètre opérationnel exposé dans le tableau ci-dessus. L'invocation de l'Art. 49 est consignée dans une entrée Art. 30 (1)(e) RGPD de notre registre des activités de traitement (compte par compte, puisque la base n'est engagée que sur les comptes qui ont affirmativement configuré le canal) plutôt que dans une TIA de mécanisme de transfert, format des Lignes directrices 2/2018 du CEPD pour l'invocation de l'Art. 49.
Datation par version du statut DPF. Le statut de certification DPF de chaque destinataire US identifié ci-dessus est vérifié à la date Dernière mise à jour : figurant en haut de la présente Politique. Les certifications DPF peuvent être accordées, suspendues ou retirées entre les révisions de politique — X Corp., par exemple, a figuré et disparu de la liste active plus d'une fois depuis l'entrée en vigueur du cadre au titre de la Décision d'exécution (UE) 2023/1795. Nous re-vérifions la liste DPF à chaque révision de politique ; dans l'intervalle, les CCT (Décision d'exécution (UE) 2021/914) sont maintenues comme repli automatique pour chaque destinataire US, indépendamment du statut DPF actuel, de sorte qu'aucun transfert ne dépende jamais uniquement d'un statut que nous n'avons pas tout juste re-vérifié. Le module CCT sélectionné par destinataire, les mesures supplémentaires et les copies des Évaluations d'Impact de Transfert par destinataire sont versionnés en interne et réémis chaque fois que les faits sous-jacents changent.
Mécanismes de résolution des litiges DPF — vos droits contre le destinataire. Les destinataires certifiés au titre du Data Privacy Framework UE-US sont tenus, en condition de certification, de se conformer aux Principes du DPF, de fournir un mécanisme de recours indépendant sans frais pour la personne concernée (chaque organisation certifiée en désigne un — typiquement TRUSTe, BBB EU Privacy Shield, JAMS, l'AAA-ICDR, le panel des Autorités de protection des données de l'UE pour les données RH, ou un autre prestataire approuvé) et, comme option contraignante de dernier recours, de participer à un arbitrage contraignant devant le DPF Panel au titre de l'Annexe I des Principes DPF. Ils sont soumis aux pouvoirs d'enquête et d'application de la Federal Trade Commission des États-Unis (ou, pour certains secteurs, du Département des Transports des États-Unis), et à la supervision du Département du Commerce des États-Unis. Vous pouvez invoquer ces voies directement contre le destinataire certifié si vous pensez que ce destinataire a violé ses engagements DPF à l'égard de vos données à caractère personnel — typiquement en déposant d'abord une plainte auprès du destinataire, puis en l'escaladant vers le mécanisme de recours indépendant désigné dans le registre de certification DPF du destinataire à https://www.dataprivacyframework.gov, et ultimement en saisissant la FTC ou en invoquant l'arbitrage du DPF Panel. Le destinataire est tenu d'identifier le mécanisme de recours indépendant applicable dans son propre avis de confidentialité et dans son entrée de certification DPF sur dataprivacyframework.gov ; nous recommandons que vous consultiez l'entrée de certification du destinataire pour la désignation actuelle. Rien dans le présent paragraphe ne déplace votre droit d'introduire une réclamation auprès de votre autorité de contrôle UE/EEE compétente au titre de l'Art. 77 RGPD ou de poursuivre des recours juridictionnels au titre des Art. 78-79 RGPD — ces recours restent disponibles en parallèle avec les voies DPF.
Délégué à la protection des données
Nous avons évalué les critères de l'Art. 37 (1) RGPD et du § 38 Abs. 1 BDSG. Le § 38 Abs. 1 BDSG exige la désignation d'un DPO sur trois bases indépendantes : (a) la base d'effectif — 20 personnes ou plus occupées en permanence au traitement automatisé de données à caractère personnel (seuil relevé de 10 à 20 par la 2. DSAnpUG-EU du 20 novembre 2019, en vigueur depuis le 26 novembre 2019) ; (b) la base AIPD — traitement soumis à une analyse d'impact relative à la protection des données au titre de l'Art. 35 RGPD indépendamment de l'effectif ; et (c) la base de transfert commercial ou de recherche — traitement commercial de données à caractère personnel aux fins de transfert, de transfert anonymisé ou de recherche de marché ou d'opinion, à nouveau indépendamment de l'effectif. Nous ne remplissons aucune des trois bases. Pour (a), nous n'atteignons pas le seuil de 20 personnes. Pour (b), notre traitement n'est pas soumis à une AIPD : il ne figure pas sur la liste de la BlnBDI au titre de l'Art. 35 (4) des opérations de traitement nécessitant une AIPD, et notre propre auto-évaluation au titre de l'Art. 35 (1) — petit service d'observabilité B2B, pas de données de catégorie particulière comme activité principale, pas de surveillance systématique à grande échelle de personnes physiques dans leur vie privée, pas de décision automatisée à effet juridique ou similairement significatif en dehors du flux étroit de fraude au paiement décrit au § 8 (qui est lui-même autorisé sur la passerelle de droit de l'Union habilitant de l'Art. 22 (2)(b), avec l'Art. 22 (2)(a) comme repli uniquement) — conclut qu'aucune opération de traitement individuelle n'atteint le déclencheur de l'Art. 35 (1) « susceptible d'engendrer un risque élevé ». Pour (c), nous ne traitons pas commercialement de données à caractère personnel aux fins de transfert à des tiers, de transfert anonymisé ou de recherche de marché ou d'opinion ; le Service est un outil d'observabilité payant, non une activité de courtage de données, de location de listes ou de panel de recherche. Nous ne sommes donc pas tenus de désigner un DPO. Les questions relatives à notre traitement de données à caractère personnel peuvent être adressées à privacy@uptimia.com ; Andrius Gecius (Geschäftsführer) est le point de contact responsable.
16. Liens vers d'autres sites web
Le Service peut contenir des liens vers des sites web tiers. Nous n'avons aucun contrôle sur et n'acceptons aucune responsabilité pour les pratiques de confidentialité ou le contenu de ces sites web. Nous vous encourageons à lire la politique de confidentialité de tout site web que vous visitez.
17. Modifications de la présente politique
Nous pouvons mettre à jour la présente Politique de confidentialité de temps à autre. Lorsque nous le faisons, nous mettrons à jour la date Dernière mise à jour : en haut du présent document et incrémenterons la version. Pour les modifications matérielles — en particulier toute modification affectant la base juridique du traitement, les catégories de destinataires de vos données à caractère personnel ou les transferts internationaux — nous vous donnerons un avis prééminent (tel qu'une notification par courriel) au moins 30 jours avant que la modification ne prenne effet.
Vous ne perdez aucun droit, et vous ne conférez aucun droit nouveau, en continuant à utiliser le Service.
18. Nous contacter
Pour les questions, préoccupations ou pour exercer vos droits au titre de la présente politique, contactez le responsable du traitement identifié au § 2 :
JJ Online GmbH (exploitant Uptimia)
Schönhauser Allee 163, 10435 Berlin
Allemagne
Téléphone : +49 151 12032902
Courriel — général : admin@uptimia.com
Courriel — confidentialité et demandes des personnes concernées : privacy@uptimia.com
Pour les sujets relevant du rôle de sous-traitant (vos données de visiteurs / utilisateurs finaux transitant par Uptimia), voir le DPA.