← Tous les articles

consultant

Article 6 RGPD: l’amende Poste Italiane éclaire intérêt légitime vs consentement

Le Garante italien inflige 12,5 M€ à Poste Italiane/PostePay pour des accès intrusifs aux terminaux via apps, sans base légale valable. Message clé: ce qui dépasse le strict nécessaire requiert souvent un vrai consentement, pas l’intérêt légitime.

Excerpt — Le 17 avril 2026, le Garante italien a infligé 12,5 M€ à Poste Italiane/PostePay pour des accès intrusifs aux appareils mobiles via leurs apps, sans base légale valable. Le message est clair: ce qui relève du « confort/sécurité plus » exige souvent un vrai consentement, pas l’intérêt légitime.

L’affaire

Par son provvedimento n° 237 du 17 avril 2026, assorti d’un communiqué du 20 avril, le Garante per la protezione dei dati personali a sanctionné Poste Italiane S.p.A. (6,624 M€) et Postepay S.p.A. (5,877 M€), au total plus de 12,5 M€, pour plusieurs manquements RGPD liés au fonctionnement des applications BancoPosta et PostePay. Les apps accédaient à des données contenues dans les terminaux (vérifications anti‑malware, télémétrie, etc.) sans base légale appropriée, avec des insuffisances d’information (art. 13), de privacy by design (art. 25), de sécurité (art. 32), d’AIPD (art. 35) et au regard de l’article 122 du Code italien (règles ePrivacy sur l’accès/stockage dans l’équipement terminal). Le Garante rejette notamment l’invocation de la PSD2/RTS comme « base légale générique » couvrant ces lectures de terminal. [Lien décision] et [communiqué]. (garanteprivacy.it)

Point clé pour les dirigeants: les autorités s’appuient désormais sur la méthode de calcul des amendes du CEPD (Guidelines 04/2022), que le Garante cite expressément pour caractériser la gravité et calibrer le montant. (gpdp.it)

Le raisonnement juridique

  • Le principe: tout traitement doit reposer sur UNE base de licéité de l’article 6 RGPD (consentement; contrat; obligation légale; intérêt vital; mission d’intérêt public; intérêt légitime). La CNPD renvoie au texte intégral (chapitre II) et rappelle la nécessité d’identifier clairement la base avant tout traitement. (cnpd.public.lu) — Voir également le cadre RGPD pour les obligations connexes.
  • Intérêt légitime (art. 6(1)(f)): il suppose une mise en balance documentée, la nécessité du traitement et le respect des droits des personnes. La CNPD le rappelle y compris dans des dossiers sectoriels (services de paiement): certains traitements de prévention de fraude peuvent relever de l’intérêt légitime, mais à des conditions strictes et avec une balance sérieuse. (cnpd.public.lu)
  • Consentement (art. 6(1)(a)): il doit être libre, spécifique, éclairé et univoque; l’EDPB (Guidelines 05/2020) interdit notamment le « forcing » (mur de cookies, consentement groupé) et exige une preuve et une possibilité de retrait facile. (edpb.europa.eu)
  • Règles ePrivacy (accès/stockage dans les terminaux): au Luxembourg, la CNPD rappelle que la lecture/écriture sur un terminal (cookies, SDK, identifiants, « device fingerprinting ») requiert un consentement préalable sauf rares exemptions techniques. Ces lignes couvrent aussi les apps mobiles, pas seulement les sites web. (cnpd.public.lu)
  • Application au cas Poste Italiane/PostePay: le Garante estime que l’accès aux données du terminal dans un objectif présenté comme « sécurité/anti‑malware » ne peut être couvert par une référence générique à la PSD2/RTS EBA; il faut une base RGPD adéquate (souvent le consentement) et une information claire. C’est précisément ce que le provvedimento n° 237 constate, en sanctionnant également des lacunes de privacy by design/sécurité/DPIA. (garanteprivacy.it)
  • Méthodologie d’amende: le Garante se réfère aux Guidelines 04/2022 du CEPD (version 2.1, 24 mai 2023) qui uniformisent la détermination du montant à travers cinq étapes, en tenant compte de la nature, gravité et durée, nombre d’intéressés, etc. Les régulateurs de l’UE convergent désormais vers cette méthode, y compris pour des violations « base légale ». (edpb.europa.eu)

Ce que ça change concrètement (Luxembourg, 2026)

  • Pour les banques/assureurs/fintechs (PSF compris) opérant des apps mobiles: l’argument « sécurité/antifraude » n’emporte pas tout. Accéder au terminal (scans anti‑malware, détection de jailbreak, collecte d’empreintes d’appareil, SDK analytiques élargis) tombe en principe sous le régime ePrivacy → consentement préalable, sauf si vous prouvez une exemption strictement technique. La CNPD a déjà fixé ce cadre pour cookies/traceurs et l’étend aux apps. (cnpd.public.lu)
  • Pour les responsables RGPD: l’arbitrage « intérêt légitime vs consentement » doit être tracé traitement par traitement. Les contenus de sécurité « nécessaires » (ex: authentification, intégrité de session) pourront être argumentés; mais les lectures « confort/risque hypothétique » exigent souvent un consentement distinct, granulaire, et révocable sans dégrader l’accès au service de base. EDPB 05/2020 le rappelle. (edpb.europa.eu). Pour structurer cette gouvernance, un mandat DPO peut piloter les analyses de base légale et la conformité continue.
  • Pour les équipes sécurité/CISO: lorsque vous ajoutez des contrôles côté terminal dans une app (anti‑bot, device attestation, score de risque), intégrez systématiquement:
    1. une AIPD si le risque est élevé (art. 35),
    2. une analyse ePrivacy (accès terminal = consentement?),
    3. une base RGPD claire (6(1)(f) ou 6(1)(a)),
    4. une minimisation technique (pas de collecte excédentaire),
    5. des mentions d’information in‑app explicites.
    Le défaut sur l’un de ces axes conduit aujourd’hui à des amendes substantielles, comme l’illustre le cas italien. (garanteprivacy.it)
  • Pour les juristes/compliance: l’invocation d’un « cadre sectoriel » (ex: PSD2/RTS) ne se substitue jamais à l’article 6 RGPD. La CNPD elle‑même, dans ses lignes sectorielles « services de paiement », rappelle la prudence: seule la prévention de fraude « strictement nécessaire » peut, parfois, relever de l’intérêt légitime après une vraie balance. (cnpd.public.lu)

Pièges fréquents observés en audit

  1. Mélanger « sécurité nécessaire » et « sécurité de confort ». Un contrôle « nice‑to‑have » (scans étendus du terminal, collecte d’ID publicitaires, corrélations marketing/risque) n’est pas « nécessaire » au sens de 6(1)(f). Documentez par user story ce qui est indispensable au service de base (authentifier, chiffrer, empêcher l’usurpation) et ce qui ne l’est pas. (edpb.europa.eu)
  2. Plaquer la PSD2 comme « parapluie » juridique. La conformité financière ou les RTS EBA ne confèrent pas automatiquement une base RGPD pour lire des informations sur l’appareil. Faites l’exercice: quelle disposition précise impose ce traitement? À défaut, basculez sur le consentement ou réduisez la portée. (garanteprivacy.it)
  3. Oublier l’ePrivacy dans les apps. Les équipes mobiles pensent parfois « cookies = web ». Faux: les SDK/identifiants/stockages/appels système sont évalués comme des traceurs/accès terminal. La CNPD l’indique expressément dans ses lignes « cookies & autres traceurs »; prévoir des mécanismes de recueil/gestion des choix in‑app. (cnpd.public.lu)
  4. Consentement non valable. « J’accepte tout » au premier lancement, sans granularité ni retrait simple, n’est pas un consentement libre et spécifique. Reprenez les exigences EDPB 05/2020: granularité par finalité, absence de conditionnement indu, preuve du consentement, retrait aussi facile que le donner. (edpb.europa.eu)
  5. AIPD et privacy by design en « après‑coup ». Dans le cas italien, le Garante vise aussi art. 25/35. Si votre dispositif élève le risque (profilage de terminal, scores), l’AIPD doit précéder le déploiement, avec choix techniques explicités (minimisation, chiffrement, durées, journalisation). (garanteprivacy.it)

Décision tree concret: intérêt légitime ou consentement pour vos apps

  • Étape 1 — Le traitement est‑il strictement nécessaire au service demandé par l’utilisateur (exécution du contrat) ou à sa sécurité immédiate? Si oui, testez 6(1)(b)/(f). Sinon, basculez vers 6(1)(a) avec recueil explicite. (edpb.europa.eu)
  • Étape 2 — Accédez‑vous/stockez‑vous des données sur le terminal (ID appareil, télémétrie, empreintes, détection root/jailbreak)? Si oui, appliquez d’abord ePrivacy: consentement préalable sauf exemption technique; si consentement, il doit aussi satisfaire l’article 6. (cnpd.public.lu)
  • Étape 3 — Mise en balance 6(1)(f): démontrez la nécessité, la proportionnalité et les mesures d’atténuation (opt‑out, minimisation, pseudonymisation). Si la balance est douteuse, privilégiez le consentement. (cnpd.public.lu)
  • Étape 4 — Information et preuve: l’information doit être immédiate et claire dans l’app (art. 13), et vous devez pouvoir prouver la base (consent logs) et les choix (préférences paramétrables). Référez‑vous aux exigences EDPB 05/2020. (edpb.europa.eu)

Sources officielles

Enseignement opérationnel: en 2026, toute lecture/écriture sur l’appareil d’un client qui dépasse le strict nécessaire au service/sécurité de base doit être considérée « consent‑requise » et traitée comme telle (parcours explicite, granularité, réversibilité). Le cas Poste Italiane/PostePay montre que les autorités n’hésitent plus à sanctionner lourdement l’erreur de base légale — même lorsqu’elle est commise au nom de la « sécurité ».

Besoin d’un appui pour cadrer vos bases légales et vos parcours de consentement dans les apps? Échangez avec notre équipe via notre page de contact.

Article d'expertise Luxgap. Pour un cadrage personnalise sur ce sujet, contactez-nous ou configurez votre devis en ligne.

NEWSLETTER LUXGAP

Recevez nos analyses des qu'elles sortent.

Articles d'expertise RGPD, NIS 2, IA, et invitations aux webinaires + formations gratuites Luxgap. 1 a 2 emails par semaine maximum, desabonnement en un clic.

Vos donnees ne sont jamais partagees. Conformite RGPD garantie (logique : on est DPO).

Une question sur ce sujet ?

Notre équipe répond généralement sous 24 h ouvrées. Configurez votre devis ou écrivez-nous.

Configurer mon devis →