# Déclaration de protection des données sur le site web en Suisse : modèle + guide d'implémentation

> Intégrer la déclaration de confidentialité au site : accessibilité, mise en œuvre dans le CMS, bannière cookies, versions linguistiques et versionnage.

- Source: https://www.sidd.swiss/fr/perspectives/declaration-de-protection-des-donnees-sur-le-site-web-en-suisse-modele-guide-dim/
- Langue: fr-CH
- Publié: 2026-05-24
- Mise à jour: 2026-05-24
- Auteur·e: Marc Grob
- Éditeur: SIDD Institut pour la protection des données et la sécurité des données, une marque de Priverion GmbH, Zugerstrasse 32, 6340 Baar (ZG), Suisse

## Introduction

Une déclaration de protection des données au contenu correct manque son objectif si elle est mal intégrée sur le site web : inaccessible depuis chaque sous-page, absente dans chaque version linguistique, non coordonnée avec le bandeau cookies, sans URL stable et sans cachet de version. Cet article s'adresse aux responsables web et aux agences externes qui doivent intégrer une déclaration de protection des données conforme à la LPD dans des systèmes CMS tels que WordPress, Webflow, Wix ou Shopify, y compris l'intégration du bandeau cookies, la maintenance multilingue et le versionnement démontrable.

Thèmes abordés :

- les cinq exigences relatives à l'accessibilité de la déclaration de protection des données selon l'art. 19 LPD ;
- intégration spécifique aux CMS dans WordPress, Webflow, Wix et Shopify ;
- cohérence entre le bandeau cookies, la plateforme de gestion du consentement et la déclaration ;
- multilinguisme DE/FR/IT/EN avec contenu synchrone et URL de langue stables ;
- structure d'URL et d'ancres stables pour les liens profonds depuis les e-mails et les CGV ;
- versionnement avec date d'entrée en vigueur et archivage des versions précédentes comme pièces à conviction ;
- l'obligation de mise à jour lors de chaque nouvel outil ou sous-traitant.

L'objectif est une déclaration de protection des données qui évolue avec chaque modification fonctionnelle du site web, et dont il est démontrable dans une procédure du PFPDT qu'elle existait dans sa version actuelle au moment de la collecte des données.

## Accessibilité et intégration dans le pied de page

L'art. 19 al. 1 LPD exige une information « adéquate ». Dans l'interprétation du PFPDT, cela inclut l'accessibilité : la déclaration de protection des données doit être accessible depuis chaque sous-page en un maximum d'un clic. Cela signifie concrètement : lien dans le pied de page persistant, visible sans faire défiler, en taille de police suffisante (au moins 12 px), libellé clairement « Déclaration de protection des données » ou « Protection des données ». Un libellé tel que « Mentions légales » ou « Legal » seul n'est pas assez explicite.

Les meilleures pratiques comprennent cinq exigences :

1. **Pied de page persistant** sur chaque page, chaque langue et dans le flux de paiement.
2. **URL stable** telle que /protection-des-donnees ou /privacy, qui devrait encore être valable dans 5 ans. Redirections permanentes (301) en cas de changement de chemin.
3. **Ancres dans le document** (#finalites, #destinataires, #pays-tiers), pour permettre des liens profonds depuis les e-mails de confirmation et les CGV.
4. **Autorisation pour les robots d'indexation**, la déclaration de protection des données devrait rester indexable, non bloquée dans robots.txt.
5. **Feuille de style d'impression**, pour pouvoir répondre aux demandes d'accès avec un instantané imprimable.

Dans les flux de paiement (e-commerce, formulaires de candidature, inscription à la newsletter), un texte de notification avec lien vers la section pertinente de la déclaration de protection des données doit en outre figurer au point de collecte des données, l'art. 19 al. 1 LPD exige l'information « lors de la collecte ».

## Intégration spécifique aux CMS

**WordPress** : créer une page de type « Page », la marquer dans le Customizer comme « Page de politique de confidentialité » (Réglages > Confidentialité). Cela active le hook natif WP pour les plugins qui documentent eux-mêmes leur traitement de données (Contact Form 7, WooCommerce). Lien dans le pied de page via le Customizer du thème ou l'éditeur de blocs. Attention : les plugins de cache doivent être configurés pour que les mises à jour de la déclaration de protection des données soient immédiatement visibles, une livraison différée est considérée comme une information obsolète.

**Webflow** : collection CMS « Legal Pages » avec les champs Titre, Slug, Corps et Date d'entrée en vigueur. Lien dans le pied de page via la mise en page globale. Localisation via Webflow Localization (DE/FR/IT/EN), important : gérer la Date d'entrée en vigueur comme champ personnalisé, pas via le champ standard « Updated », car ce dernier change à chaque enregistrement.

**Wix / Squarespace** : page dédiée « Politique de confidentialité », entrée dans la navigation du site comme élément de pied de page. Multilinguisme via les modules Multilingual, dans Wix, les URL de langue sont structurées comme /fr/protection-des-donnees, ce qui convient à l'indexation par les moteurs de recherche.

**Shopify** : page « Légal » native (Paramètres > Politiques > Politique de confidentialité), automatiquement liée dans le checkout. Quiconque exploite un site Shopify pour la Suisse devrait remplacer le texte par défaut RGPD par une version conforme à la LPD, le modèle standard est centré sur le RGPD et présente des lacunes LPD en matière de transferts vers des pays tiers et de profilage.

Des instructions CMS détaillées se trouvent dans nos articles [Déclaration de protection des données Shopify Suisse](https://www.sidd.swiss/einblicke/shopify-datenschutzerklaerung-schweiz) et [Déclaration de protection des données Wix Suisse](https://www.sidd.swiss/einblicke/wix-datenschutzerklaerung-schweiz).

## Bandeau cookies et gestion du consentement

La déclaration de protection des données et le bandeau cookies sont liés sur le fond. Les incohérences, le bandeau liste un outil absent de la déclaration, ou inversement, sont régulièrement le premier point de reproche dans les procédures du PFPDT. En Suisse, le bandeau doit être conçu de manière transparente et avec possibilité d'opposition selon l'art. 45c lit. b de la loi sur les télécommunications ; un consentement actif (« opt-in ») n'est impératif que pour les cookies de suivi publicitaire avec lien UE selon le RGPD/ePrivacy.

Une architecture intégrée comprend :

- **Plateforme de gestion du consentement (CMP)** telle que Cookiebot, Usercentrics ou Iubenda, qui scanne automatiquement tous les cookies installés et leurs fournisseurs et tient un journal de consentement versionné.
- **Tableau des cookies dans la déclaration de protection des données**, exporté depuis la CMP et identique à la liste affichée dans le bandeau.
- **Catégories granulaires** (Nécessaire / Statistiques / Marketing / Médias externes), pas uniquement « Tout accepter » et « Nécessaires ».
- **Possibilité de réaccès simple** au bandeau (lien pied de page « Paramètres des cookies »), afin qu'un consentement puisse être retiré à tout moment.

Pour les outils avec backend américain (Google Analytics, HubSpot, Meta Pixel), le transfert vers des pays tiers doit figurer dans la déclaration, avec mention de la certification Swiss-U.S. DPF ou des clauses contractuelles types. Modèles détaillés de bandeau : [Bandeau cookies Suisse](https://www.sidd.swiss/einblicke/cookie-banner-schweiz).

## Multilinguisme et URL de langue

Quiconque exploite un site web suisse multilingue doit maintenir la déclaration de protection des données dans chaque langue publiée, pas seulement dans les langues officielles du siège, mais dans chaque langue dans laquelle l'offre est effectivement commercialisée. Dans les versions linguistiques où la déclaration est absente, l'information est considérée comme non « adéquate » au sens de l'art. 19 al. 1 LPD.

Trois décisions d'architecture :

1. **URL de langue stables** telles que /datenschutz, /fr/protection-des-donnees, /it/protezione-dei-dati, /en/privacy. Avec annotations hreflang pour les moteurs de recherche.
2. **Contenu synchrone** : quiconque modifie une version linguistique doit mettre à jour les autres. Un processus de révision documenté (« synchronisation linguistique avant publication ») est le standard. En cas de divergence, la version dans la langue du contrat fait foi en cas de litige, pour les PME suisses, typiquement l'allemand.
3. **Contacts spécifiques par langue** uniquement là où cela est judicieux, p. ex. une boîte aux lettres en français pour les clients romands. Si aucun point de contact spécifique à la langue n'existe, indiquer l'adresse centrale dans chaque version linguistique plutôt que de créer une adresse locale fictive.

Quiconque travaille avec des prestataires de traduction devrait marquer explicitement la déclaration de protection des données comme « document à portée juridique », le circuit de traduction marketing standard ne suffit pas ici, car les termes juridiques (p. ex. « destinataire » vs. « catégorie de destinataires ») doivent être rendus avec précision.

## Versionnement, date d'entrée en vigueur, archivage

Une déclaration de protection des données sans indication de version visible est difficile à défendre en cas de litige. Le standard est un cachet de version à la fin de la déclaration (« Version 3.2, en vigueur depuis le 1er mars 2026 ») et un chemin d'archivage interne conservant chaque version précédente sous forme de PDF instantané pendant au moins 10 ans, à l'instar des obligations de conservation selon l'art. 958f CO pour les documents commerciaux.

Recommandations opérationnelles :

- En cas de modifications substantielles (nouvelle catégorie de données, nouveau sous-traitant, nouveau destinataire dans un pays tiers, nouveau profilage), informer activement les utilisateurs enregistrés par e-mail et respecter la période de transition de 14-30 jours.
- Pour les simples modifications de formulation sans nouvelles mentions obligatoires, la publication silencieuse avec nouveau cachet de version suffit.
- Générer automatiquement des instantanés PDF archivés lors de l'événement de publication, signés avec horodatage, les horodatages qualifiés selon la SCSE sont convaincants dans une procédure, les horodatages UTC simples suffisent pour la majorité des cas.
- Journal des modifications interne avec différence par rapport à la version précédente et justification de l'adaptation, comme preuve d'une maintenance correcte dans une procédure du PFPDT selon les art. 49-53 LPD.

Quiconque maintient la déclaration de protection des données manuellement devrait effectuer au minimum une vérification de plausibilité par rapport au registre des activités de traitement (art. 12 LPD) tous les six mois.

## Déclencheurs de mise à jour et cycles de maintenance

La déclaration de protection des données doit refléter à tout moment le traitement réel des données. Sur la base de plus de 200 audits SIDD de 2024-2025, sept déclencheurs de mise à jour ressortent :

1. **Nouveau sous-traitant** (p. ex. changement d'outil de newsletter, nouveau fournisseur CRM, nouveau système helpdesk).
2. **Nouvelle catégorie de destinataires** (p. ex. première transmission à une agence de recouvrement).
3. **Nouveau transfert vers un pays tiers** (p. ex. migration d'un fournisseur cloud UE vers un fournisseur cloud américain).
4. **Nouvelle catégorie de données** ou premier traitement de données personnelles particulièrement dignes de protection (art. 5 lit. c LPD).
5. **Nouvelle finalité** (p. ex. introduction d'un programme de fidélité, nouveau canal marketing).
6. **Nouveau système de décision automatisé** ou profilage (art. 21 LPD, avec éventuellement obligation d'AIPD selon l'art. 22 LPD).
7. **Modification législative substantielle** (p. ex. nouvelles recommandations du PFPDT, nouvelles lignes directrices RGPD du CEPD, nouvelles CCT suisses).

Une procédure de maintenance documentée, typiquement sous forme de matrice RACI entre marketing, informatique, juridique et DPO, évite que la déclaration de protection des données diverge de l'état réel du traitement après 12-18 mois.

## Comment SIDD vous accompagne

SIDD prend en charge la création et la maintenance continue de la déclaration de protection des données typiquement dans le cadre d'un [mandat DPO](https://www.sidd.swiss/fr/services/conseiller-protection-donnees-suisse). La maintenance opérationnelle s'effectue via la [plateforme Priverion](https://www.sidd.swiss/fr/priverion-plateforme), qui gère le registre des activités de traitement, l'inventaire des contrats de sous-traitance et la déclaration de protection des données dans un seul modèle de données, les modifications dans le registre des sous-traitants se propagent automatiquement dans la déclaration publiée. Pour les sites Webflow et WordPress, nous proposons des packages d'intégration prêts à l'emploi avec synchronisation automatique des langues.

Pour le bandeau cookies, nous aidons à la sélection et à la configuration d'une CMP ainsi qu'à la coordination entre le bandeau et la déclaration. Quiconque est en outre soumis au RGPD, nous complétons avec le [DPO RGPD](https://www.sidd.swiss/fr/services/delegue-protection-donnees-rgpd) et le [représentant UE](https://www.sidd.swiss/fr/services/representant-ue-rgpd). Un audit de votre intégration web actuelle (pied de page, bandeau cookies, versions linguistiques, versionnement) dure généralement 90 minutes, demande via [notre formulaire de contact](https://www.sidd.swiss/fr/contact) ; pour un mandat à prix fixe concret pour la création et l'intégration, utilisez la [demande d'offre](https://www.sidd.swiss/fr/devis).

---

Ce document est la version Markdown de la page liée ci-dessus. Merci de citer l'URL HTML.