Table des matières
Une fuite de données dans votre dispositif de mesure ne se règle pas en corrigeant une configuration. Dès que la violation est susceptible d'entraîner un risque élevé pour la personnalité ou les droits fondamentaux des personnes concernées, l'art. 24 LPD vous oblige à l'annoncer au PFPDT dans les meilleurs délais. Et si les personnes concernées peuvent se protéger elles-mêmes, vous devez les informer, même quand le risque n'atteint pas ce seuil. Le droit suisse ne fixe aucun délai en heures, contrairement aux 72 heures du RGPD, mais il ne vous accorde pas pour autant le droit de temporiser.
Dans la pratique, les fuites qui touchent les équipes marketing ne viennent presque jamais d'une cyberattaque spectaculaire. Elles viennent d'un formulaire qui pousse une adresse e-mail en clair dans une URL, d'un conteneur server-side qui journalise des données qu'il ne devrait pas conserver, d'un export CRM partagé au mauvais endroit. Ce sont des incidents discrets, techniques, et pourtant pleinement couverts par la LPD.
L'essentiel en huit points
Annonce au PFPDT : obligatoire uniquement si la violation entraîne vraisemblablement un risque élevé pour la personnalité ou les droits fondamentaux de la personne concernée (art. 24 al. 1 LPD).
Délai suisse : dans les meilleurs délais. Aucune durée chiffrée dans la loi, à la différence des 72 heures de l'art. 33 RGPD.
Contenu minimal de l'annonce : la nature de la violation, ses conséquences et les mesures prises ou envisagées (art. 24 al. 2 LPD).
Information des personnes concernées : due lorsqu'elle est nécessaire à leur protection ou lorsque le PFPDT l'exige (art. 24 al. 4 LPD). Ce devoir ne dépend pas du seuil de risque élevé.
Si vous êtes sous-traitant : vous annoncez au responsable du traitement toute violation, sans filtre de gravité (art. 24 al. 3 LPD).
Documentation : les violations doivent être documentées et conservées au moins deux ans à compter de l'annonce (art. 15 OPDo).
Sanction : le défaut d'annonce n'est pas lui-même pénalement sanctionné en droit suisse. Le manquement aux exigences minimales de sécurité l'est, sur plainte, jusqu'à 250 000 francs (art. 61 let. c LPD).
Volume réel : le PFPDT indique avoir reçu plus de 2000 annonces de violations potentielles au cours de l'année sous revue de son 33e rapport d'activités, publié fin juin 2026.
Qu'est-ce qu'une violation de la sécurité des données dans un dispositif de mesure ?
La LPD ne définit pas la violation par son origine mais par son effet : une atteinte à la sécurité entraînant une perte, une suppression, une destruction ou une modification involontaire ou illicite de données personnelles, ou encore leur divulgation ou leur accessibilité à des personnes non autorisées. Aucune intrusion n'est requise. Une erreur de configuration suffit.
C'est précisément ce qui rend le sujet pertinent pour un dispositif de tracking. Un dispositif de mesure moderne, c'est une chaîne : navigateur, gestionnaire de balises, conteneur server-side, plateformes publicitaires, CRM, outils de dashboarding. Chaque maillon manipule des identifiants, parfois des données de contact, et chacun peut fuir sans que personne ne s'en aperçoive.
Les scénarios les plus fréquents dans un stack marketing
L'adresse e-mail en clair dans l'URL. Un formulaire soumis en GET, ou une redirection de remerciement qui recopie les champs du formulaire dans les paramètres de requête. L'adresse part alors dans le referrer, dans les journaux du serveur, dans l'outil d'analytics et chez les régies publicitaires appelées depuis cette page.
La journalisation trop généreuse côté serveur. Un conteneur server-side configuré en mode debug prolongé, ou un service de journalisation qui conserve les charges utiles complètes des événements. Vous vous retrouvez avec un historique de données de contact dans un entrepôt que personne n'a classé comme sensible.
Le paramètre de personnalisation qui voyage trop loin. Un identifiant client, un numéro de dossier ou un numéro de patient utilisé comme dimension personnalisée, puis transmis à une plateforme publicitaire qui n'avait aucune raison de le recevoir.
L'export mal rangé. Un fichier de leads déposé dans un espace de stockage partagé, un tableau d'audiences envoyé par messagerie, un rapport exposé par un lien public non expirant.
L'indexation accidentelle. Le cas le plus brutal, parce qu'il transforme une erreur de configuration en publication mondiale. Charlotte Beck et Alain Steinmann ont analysé fin septembre 2026 sur swissprivacy.law une affaire dans laquelle les fiches de plusieurs milliers de clients d'une boutique en ligne, comportant notamment identité, adresses et coordonnées bancaires, se sont retrouvées indexées par un moteur de recherche à la suite d'un défaut de sécurité. L'entreprise avait bloqué l'accès puis refusé d'informer sa clientèle, en jugeant l'effort disproportionné.
Aucun de ces cinq scénarios ne ressemble à une cyberattaque. Tous relèvent pourtant de l'art. 24 LPD dès lors que des données personnelles ont été rendues accessibles à des tiers non autorisés.
Qui devez-vous prévenir, et dans quel délai ?
Il y a deux obligations distinctes, deux destinataires et deux seuils différents. Les confondre est l'erreur la plus courante.
L'annonce à l'autorité
Sous la LPD : le responsable du traitement annonce au PFPDT, dans les meilleurs délais, les violations entraînant vraisemblablement un risque élevé pour la personnalité ou les droits fondamentaux de la personne concernée. Le seuil est donc double : un risque, et un risque élevé. En dessous, aucune annonce n'est due.
Sous le RGPD : la notification à l'autorité de contrôle est due dès qu'il existe un risque pour les droits et libertés, et elle doit intervenir dans les meilleurs délais et si possible 72 heures au plus tard après la prise de connaissance. Le seuil est plus bas, le délai est chiffré.
Conséquence pratique : une entreprise suisse qui adresse aussi une clientèle dans l'Union européenne doit raisonner sur le régime le plus exigeant des deux. Si vous voulez le détail de cette articulation, notre comparaison technique entre la LPD et le RGPD la reprend point par point.
L'annonce obligatoire au PFPDT se fait par son portail dédié. Sylvain Métille, avocat à Lausanne, rappelle sur son blog que ce portail est réservé aux annonces obligatoires et que les annonces spontanées suivent une autre voie. Il relève aussi, à juste titre, que l'absence de délai chiffré en droit suisse doit laisser au responsable le temps d'établir les faits avant de qualifier le risque.
L'information des personnes concernées
C'est ici que se joue la nuance la plus mal comprise de l'art. 24. L'alinéa 4 impose d'informer la personne concernée lorsque cela est nécessaire à sa protection ou lorsque le PFPDT l'exige. David Dias Matos et Célian Hirsch l'ont souligné sur swissprivacy.law en commentant les explications du PFPDT : ce devoir est indépendant du seuil de risque élevé qui déclenche l'annonce à l'autorité.
Le critère n'est donc pas la gravité abstraite, mais l'utilité concrète : la personne peut-elle faire quelque chose pour se protéger ? Changer un mot de passe, faire opposition sur une carte, surveiller un compte, se méfier d'une tentative d'hameçonnage qui réutiliserait les données fuitées. Si oui, vous l'informez, dans un langage simple et compréhensible, en indiquant au minimum la nature de la violation, les risques encourus et les mesures prises (art. 15 al. 3 OPDo).
Et lorsque l'information individuelle devient impossible ou disproportionnée, elle ne disparaît pas : elle se transforme en communication publique. C'est tout l'enseignement de l'affaire commentée fin septembre 2026 sur swissprivacy.law. L'ampleur d'une fuite n'est pas un argument pour se taire.
Quand le risque est-il « élevé » au sens de l'art. 24 LPD ?
La loi ne donne pas de liste. La pratique en dégage des repères, que le PFPDT a précisés et que la doctrine suisse relaie.
Le risque est présumé élevé lorsque la fuite porte sur des données sensibles, sur des copies de pièces d'identité ou de cartes de crédit, ou sur des données révélant un contexte particulièrement intrusif, par exemple des poursuites pénales ou des mesures d'aide sociale. À l'inverse, il n'y a généralement pas de risque élevé lorsque les données concernées étaient déjà publiquement accessibles avant la violation.
Pour un dispositif de mesure, cela donne une grille de lecture utile :
Quelles catégories de données ont circulé ? Un identifiant publicitaire pseudonyme n'a pas le même poids qu'une adresse e-mail associée à un panier, et encore moins qu'une donnée de santé déduite du parcours de navigation sur un site médical.
Combien de personnes sont concernées, et pendant combien de temps ? Une exposition de quelques minutes à un prestataire sous contrat n'est pas une indexation publique de plusieurs mois.
Les données permettent-elles de réidentifier quelqu'un ? Un identifiant seul, non. Un identifiant croisé avec une adresse de livraison, oui.
Les données peuvent-elles servir à nuire ? Usurpation, hameçonnage ciblé, fraude au paiement, révélation d'une appartenance ou d'un état de santé. C'est ce critère qui fait le plus souvent basculer la qualification.
La mesure corrective neutralise-t-elle vraiment le risque ? Couper l'accès ne retire pas ce qui a déjà été copié, mis en cache ou indexé.
Cette grille correspond au contenu que l'art. 15 al. 1 OPDo attend de l'annonce : nature de la violation, moment où elle s'est produite, catégories et nombre approximatif de données et de personnes touchées, conséquences et risques, mesures correctives, et interlocuteur à contacter. L'ordonnance admet par ailleurs une annonce par étapes lorsque toutes ces informations ne peuvent pas être réunies en même temps, ce qui est presque toujours le cas dans les premières heures.
Agence web, agence marketing : vous êtes probablement sous-traitant
C'est le point que beaucoup de prestataires découvrent trop tard. L'art. 24 al. 3 LPD impose au sous-traitant d'annoncer au responsable du traitement tout cas de violation de la sécurité des données, dans les meilleurs délais. Aucun seuil de risque élevé ici. Aucune marge d'appréciation sur la gravité.
Autrement dit : si vous gérez le gestionnaire de balises, le conteneur server-side, la plateforme de consentement ou le CRM de votre client, et que vous constatez une fuite, vous devez le lui dire. Y compris quand c'est vous qui avez fait l'erreur. Et c'est lui, responsable du traitement, qui décidera de l'annonce au PFPDT et de l'information de ses clients.
Trois conséquences contractuelles et opérationnelles en découlent :
Le contrat de sous-traitance doit prévoir le canal et le délai de remontée. Un simple « nous informerons le client » ne tient pas : il faut un destinataire nommé, un canal qui fonctionne hors heures de bureau, et un format d'information qui permette au responsable de qualifier le risque.
La journalisation doit être exploitable. On ne qualifie pas une fuite sans savoir ce qui est parti, vers où et pendant combien de temps. L'art. 4 OPDo impose d'ailleurs la journalisation pour les traitements à grande échelle de données sensibles et pour le profilage à risque élevé.
Le règlement de traitement n'est pas une formalité. L'art. 5 OPDo l'exige dans les mêmes hypothèses, et c'est le premier document qu'une autorité réclame. Nous avons détaillé ailleurs les documents que le PFPDT peut demander lors d'un contrôle : la documentation des violations en fait partie.
Que risquez-vous réellement en Suisse ?
Il faut être précis, parce que le sujet nourrit beaucoup d'approximations.
Le défaut d'annonce d'une violation de la sécurité des données n'est pas, en lui-même, une infraction pénale au sens des art. 60 à 62 LPD. Ces dispositions visent les manquements aux devoirs d'information des art. 19 et 21, les manquements liés au droit d'accès des art. 25 à 27, la communication de données à l'étranger en violation des art. 16 et 17, la sous-traitance non conforme à l'art. 9, et le non-respect des exigences minimales de sécurité édictées par le Conseil fédéral selon l'art. 8 al. 3. L'art. 24 n'y figure pas.
Cela ne veut pas dire qu'il n'y a pas de risque. Il est simplement ailleurs :
La cause de la fuite, elle, est sanctionnable. Une violation qui résulte du non-respect des exigences minimales de sécurité tombe sous l'art. 61 let. c LPD, puni sur plainte d'une amende pouvant aller jusqu'à 250 000 francs, et qui frappe la personne physique responsable, non l'entreprise.
Le PFPDT peut ouvrir une enquête et ordonner des mesures. L'art. 51 LPD lui permet d'ordonner la modification, la suspension ou la cessation de tout ou partie du traitement, ainsi que l'effacement ou la destruction des données. Pour un dispositif de mesure, cela peut signifier l'arrêt d'une collecte dont dépendent vos campagnes.
Le volume d'annonces montre que l'autorité est active. Son 33e rapport d'activités, publié fin juin 2026, fait état de plus de 2000 annonces de violations potentielles reçues durant l'année sous revue, de 156 interventions auprès de responsables du traitement, de 22 examens préliminaires et de 9 enquêtes.
Le risque civil et réputationnel reste le plus concret. Une action en dommages-intérêts, une plainte collective de clients, et surtout la perte de confiance d'une clientèle qui apprend la fuite par un tiers plutôt que par vous.
Les quatre réflexes des 48 premières heures
Le schéma qui accompagne cette section reprend cette séquence en quatre étapes. En voici le contenu :
Contenir, sans détruire les preuves. Couper la source de la fuite, révoquer les accès et les jetons concernés, désactiver la balise ou le flux fautif. Mais conserver les journaux, les versions de conteneur et les horodatages : c'est avec eux que vous qualifierez le risque et que vous documenterez le dossier.
Qualifier. Quelles données, combien de personnes, quelle fenêtre d'exposition, quels destinataires, quelle possibilité de réidentification et de nuisance. Vous jouez le rôle d'enquêteur, pas celui d'avocat de votre propre configuration.
Décider et annoncer. Deux décisions séparées : annonce au PFPDT si le risque est vraisemblablement élevé, information des personnes concernées si elles peuvent se protéger. Si les faits manquent, annoncez par étapes plutôt que d'attendre.
Documenter et corriger. Constituer le dossier de violation et le conserver au moins deux ans, puis traiter la cause racine, pas seulement le symptôme. Une fuite due à un formulaire en GET se répétera tant que le formulaire restera en GET.
Comment réduire la surface de fuite de votre dispositif de mesure
La meilleure annonce de violation est celle que vous n'avez pas à faire. Trois couches de prévention, du navigateur vers vos entrepôts de données :
Couche collecte. Aucune donnée de contact en clair dans les URL, les titres de page ou les dimensions personnalisées. Formulaires en POST. Nettoyage systématique des paramètres de requête avant toute transmission. Interdiction explicite, dans le plan de taggage, de pousser un identifiant métier vers une plateforme publicitaire.
Couche serveur. Un conteneur server-side est le bon endroit pour filtrer, hacher et minimiser avant de transmettre, à condition qu'il ne devienne pas lui-même un entrepôt. Débogage limité dans le temps, pas de conservation des charges utiles complètes, rotation des clés d'API, et journalisation dimensionnée pour l'enquête et non pour l'archivage. C'est aussi dans cette couche que se joue la question de l'hébergement et de la localisation des données.
Couche gouvernance. Un inventaire à jour de ce qui part où, un règlement de traitement, une procédure de violation nommant un responsable et un suppléant, et une revue périodique. C'est le seul moyen de détecter une dérive avant qu'elle ne devienne un incident. Notre article sur la surveillance d'un tracking server-side après la mise en ligne décrit le dispositif de contrôle correspondant.
Un point mérite d'être dit clairement, parce qu'on l'entend souvent à l'envers : le passage en server-side ne crée pas un risque de fuite supplémentaire par nature. Il déplace le point de contrôle. Bien configuré, il réduit la surface exposée en empêchant les données de quitter votre périmètre sans filtre. Mal configuré, il centralise au même endroit tout ce qu'il aurait dû écarter.
Comment A-Track peut vous aider
Notre travail consiste à faire en sorte que votre mesure soit à la fois fiable et défendable. Sur ce sujet précis, cela prend trois formes.
Un audit de surface de fuite, d'abord : nous inspectons ce qui circule réellement entre votre site, votre conteneur server-side et vos plateformes, dans les trois états de consentement, et nous identifions les données qui ne devraient pas y être. Ensuite, la correction : plan de taggage, filtrage server-side, politique de journalisation et procédure de violation documentée. Enfin, la maintenance : la conformité d'un dispositif de mesure ne survit pas seule à six mois de mises à jour de CMS, de plugins et de plateformes publicitaires.
Nos prestations de tracking et conformité et de gouvernance data couvrent ce périmètre pour des PME suisses, des agences web et des agences marketing.
Prochaine étape
Si vous ne savez pas, aujourd'hui, quelles données personnelles quittent votre site vers vos plateformes publicitaires, vous ne serez pas en mesure de qualifier une fuite le jour où elle se produira. Et c'est précisément ce que l'art. 24 LPD vous demandera de faire, dans les meilleurs délais.
Commencez par le plus simple : ouvrez vos journaux de conteneur, cherchez une arobase et un signe d'égalité dans vos paramètres de requête, et regardez ce qui remonte. Si quelque chose remonte, vous avez déjà votre premier chantier. Si rien ne remonte, documentez-le : c'est la première pièce de votre dossier de conformité.
Sources
Loi fédérale sur la protection des données (LPD, RS 235.1), en particulier les art. 8, 24, 51 et 60 à 62.
Ordonnance sur la protection des données (OPDo, RS 235.11), en particulier les art. 1 à 5 et l'art. 15.
PFPDT, 33e rapport d'activités 2025/2026, publié fin juin 2026.
Charlotte Beck et Alain Steinmann, « Lorsque la mitigation rend la notification impossible », swissprivacy.law, 30 septembre 2026.
David Dias Matos et Célian Hirsch, « Le PFPDT guide les responsables du traitement quant à leur devoir d'informer des violations de la sécurité des données », swissprivacy.law, 19 février 2025.
Sylvain Métille, « Violations de la sécurité des données personnelles (LPD) », smetille.ch.
