Créer une boutique en ligne suisse : protection des données, accessibilité et exploitation

Situation de départ : créer une boutique en ligne en Suisse

Quiconque crée une boutique en ligne en Suisse évolue simultanément dans trois domaines : le droit, la technique et l’exploitation. Le droit détermine ce qui est autorisé avec les données clients et quelles exigences s’appliquent en matière d’accessibilité. La technique régit l’interaction entre la boutique, le paiement et la logistique ; l’exploitation assure la sécurité, la disponibilité et la maintenabilité à long terme.

La mise en place suit ces trois domaines dans un ordre précis : d’abord le droit et l’accessibilité, puis la technique, enfin l’exploitation. Les décisions juridiques influencent la technique, et les choix techniques impactent l’exploitation. Connaître cet ordre permet de ne pas planifier ces domaines les uns contre les autres.

Ces trois champs sont désignés par leurs acronymes. Droit : LPD, LHand et OHand, ainsi que, pour les activités dans l’UE, l’EAA et le BFSG. Technique : eCH-0059, WCAG 2.1 AA, EN 301 549, systèmes de boutique comme Shopify ou Plenty, sans oublier l’hébergement web, le traitement des paiements et l’analyse web. Exploitation : mises à jour, gestion des clés, journalisation et procédures automatisées de suppression.

Le volet technique repose sur quelques piliers essentiels : le système de boutique, l’hébergement web, le traitement des paiements et l’analyse web. La boutique SIGG fonctionne sur la plateforme Shopify, qui fournit les services nécessaires. En structurant ces composants avant de choisir le système, on évite des refontes coûteuses par la suite.

Ces quatre piliers s’articulent entre eux : le système de boutique gère le catalogue, les comptes clients et le processus de commande (checkout) ; l’hébergement web diffuse les pages ; le traitement des paiements finalise l’achat ; l’analyse web fournit les chiffres utiles à l’exploitation. En définissant chaque composant séparément, il devient possible d’en remplacer un sans devoir reconstruire toute la boutique.

Le choix du système dépend de la taille de l’entreprise et des rôles nécessaires. Les grandes entreprises internationales, avec de nombreux produits et des rôles tels que Super-Admin, Admin, Rédacteur et Gestionnaire de boutique, optent pour Oracle Commerce Cloud, IBM WebSphere Commerce, SuiteCommerce d’Oracle NetSuite, SAP Commerce Cloud, Sitecore Experience Commerce, Intershop Commerce Suite, SAP Hybris Commerce ou Salesforce Commerce Cloud.

Les PME font appel à des agences digitales ou à des webdesigners locaux spécialisés dans quelques systèmes e-commerce bien précis. Aucun système n’est parfaitement préparé pour le référencement naturel (SEO) ; les affirmations du type « SEO ready » doivent être activement questionnées.

Ces agences et webdesigners se sont généralement spécialisés dans un nombre restreint de systèmes ; Plenty fait partie des solutions autour desquelles ils structurent leur offre. En choisissant un tel système, il convient de confronter la liste des fonctionnalités souhaitées aux fonctions réellement proposées.

L’étiquette « SEO ready » ne constitue pas une garantie certifiée. Pour la vérifier, il faut demander quelles fonctions sont concrètement visées et si elles correspondent à son assortiment et à sa clientèle.

Le marché est vaste : de nombreux systèmes de boutique s’adressent à différentes cibles, chacun ayant ses avantages et inconvénients. Avant de chercher un système, il est utile d’établir une liste des fonctionnalités prioritaires, afin que le donneur d’ordre, l’agence et l’équipe de développement examinent les mêmes exigences.

D’autres fonctions incluent les newsletters, les notifications push, la communication via messagerie instantanée, les plug-ins ainsi que les contenus intégrés. S’y ajoutent le Single Sign-On et l’acquisition d’applications via des app stores. Chaque fonction génère des traitements spécifiques et nécessite une section dédiée dans la déclaration de confidentialité.

La protection des données et l’accessibilité relèvent de cette phase précoce. Toutes deux influencent profondément l’architecture et les processus : champs de données, logique de consentement, flux de compte et de checkout, bibliothèque de composants et procédures de test. Si on les aborde seulement après le lancement, on doit souvent restructurer plutôt que compléter.

Les bases juridiques sont plus ou moins claires selon les sujets. Pour la clientèle en Suisse, la loi fédérale sur la protection des données (LPD) s’applique.

En matière d’accessibilité, il existe des exigences concrètes pour les organismes publics, mais aucune obligation générale de respecter les WCAG pour tous les sites web du secteur privé. L’obligation découle toutefois de l’interdiction de discriminer les personnes dans l’accès aux prestations de service offertes au public, ainsi que des prescriptions liées aux activités dans l’UE.

Les lois pertinentes sont la LPD, la LHand et l’OHand. Les normes techniques sont eCH-0059, WCAG 2.1 AA et EN 301 549.

Pour les transmissions à l’étranger, les clauses contractuelles types approuvées, établies ou reconnues au préalable par le PFPDT sont déterminantes. L’SNV représente la normalisation mondiale (ISO) et européenne (CEN) et tient la boutique de normes SNV-Connect.

Les lois déterminantes sont la LPD, la LHand et l’OHand. Les systèmes vont de Shopify à Oracle Commerce Cloud en passant par Salesforce Commerce Cloud. Les tâches d’exploitation comprennent les mises à jour, la gestion des clés, la journalisation et les procédures automatisées de suppression.

Protection des données selon la LPD suisse : bases pour la boutique

Pour les boutiques dont la clientèle se trouve en Suisse, la LPD est déterminante. Contrairement au RGPD, le droit suisse n’exige en principe pas de mentionner une base légale pour le traitement des données personnelles. Il impose toutefois un traitement conforme à la bonne foi, licite et proportionné (art. 6 al. 1 et 2 LPD).

S’y ajoute le principe de la finalité : les données personnelles ne sont collectées que pour un but déterminé, reconnaissable par la personne concernée, et ne sont traitées que d’une manière compatible avec ce but (art. 6 al. 3 LPD).

Ainsi, celui qui collecte l’adresse de livraison et l’adresse e-mail pour le traitement des commandes ne peut pas, sans autre formalité, en déduire un profil publicitaire destiné à d’autres canaux. Chaque champ de données supplémentaire et chaque utilisation additionnelle requièrent un but reconnaissable, compatible avec le traitement.

Pour la technique, cela signifie : chaque champ dans le checkout, le compte client et la newsletter doit avoir un but identifiable. Les champs sans but n’ont pas leur place dans le formulaire, et toute utilisation supplémentaire d’un champ existant constitue un traitement distinct.

Pour la boutique, cela implique : tenir un registre des traitements, documenter les finalités, réglementer les accès et maintenir la déclaration de confidentialité en cohérence avec l’exploitation réelle.

L’aperçu des traitements mentionne trois éléments : les types de données traitées, les catégories de personnes concernées et les finalités du traitement. Les catégories de personnes typiques sont les bénéficiaires de prestations et les mandants, les prospects, les partenaires de communication, les utilisateurs ainsi que les partenaires commerciaux et contractuels. Les finalités usuelles incluent l’exécution de prestations contractuelles, la communication, les mesures de sécurité et la mise à disposition de l’offre en ligne.

La liste des finalités varie selon l’entreprise. Outre l’exécution de prestations contractuelles, apparaissent des buts tels que les procédures administratives et organisationnelles, les processus organisationnels et administratifs, le feedback, l’ergonomie, l’infrastructure informatique, les relations publiques ainsi que les processus métier et les procédures économiques.

La surveillance ne s’arrête pas aux frontières de l’entreprise. Dès lors que des prestataires de services sont impliqués – traitement des paiements, hébergement, analyse –, leurs rôles et obligations doivent être clarifiés.

Les groupes de personnes concernées sont les bénéficiaires de prestations et les mandants, les prospects, les partenaires de communication, les utilisateurs, les partenaires commerciaux et contractuels ainsi que les tiers. Les finalités englobent les prestations contractuelles, la communication, les mesures de sécurité et le marketing direct.

Le registre des traitements s’enrichit avec la boutique : chaque nouveau moyen de paiement, chaque newsletter et chaque application entraîne des traitements qui doivent être recensés avant la mise en production.

Déclaration de confidentialité, cookies et comptes utilisateurs

Une déclaration de confidentialité pour une boutique en ligne commence par l’identification du responsable du traitement, avec adresse et coordonnées. Suivent ensuite un aperçu des traitements, les types de données traitées, les groupes de personnes concernées, les finalités, les destinataires, des indications sur la conservation et la suppression, ainsi que les droits des personnes concernées.

Le responsable du traitement est indiqué avec son nom, son adresse et ses coordonnées. Exemple suisse : ETA EXTENSIONS by Mirjeta Elmazi, Merkurstrasse 9, 8953 Dietikon, avec l’adresse e-mail [email protected].

Outre le responsable, un délégué à la protection des données peut être nommé, avec adresse et point de contact dédié. calimoto indique Dr. jur. Thomas Schwenke, Ansbacher Str. 65, 10777 Berlin, avec [email protected].

Un responsable du traitement peut également être établi à l’étranger : calimoto GmbH, Babelsberger Strasse 12, 14473 Potsdam, Allemagne, avec [email protected].

Les structures habituelles distinguent en outre la mise à disposition de l’offre en ligne et l’hébergement web, les procédés de paiement, les cookies, l’inscription et le compte utilisateur, la gestion des contacts et des demandes, ainsi que – en cas d’offre d’applications propres – des mentions spécifiques relatives aux applications.

D’autres sections peuvent concerner les prestations commerciales, les fonctionnalités communautaires, les présences sur les réseaux sociaux, les modifications et actualisations, ainsi que les définitions des termes.

En complément de la structuration par fonction, d’autres sections figurent. Elles portent sur les bases légales pertinentes, les mesures de sécurité, la transmission de données personnelles, les transferts internationaux de données, la conservation et la suppression des données, ainsi que les droits des personnes concernées.

Pour les applications propres, des sections supplémentaires s’ajoutent : communication via messagerie instantanée, notifications push, newsletters et notifications électroniques, analyse web, monitoring et optimisation, ainsi que marketing en ligne. S’y ajoutent l’acquisition d’applications via les app stores et l’authentification unique (Single Sign-On).

Les types de données typiques incluent les coordonnées : nom, adresse de facturation et de livraison, numéro de téléphone, adresse e-mail. S’y ajoutent les informations financières telles que les données de carte et de compte, les détails des transactions et la confirmation de paiement, ainsi que les informations de compte comme le nom d’utilisateur, le mot de passe et les paramètres.

Viennent ensuite les informations transactionnelles : articles consultés, ajoutés au panier, achetés, retournés ou annulés. Entrent également en ligne de compte le contenu des demandes clients, les informations sur l’appareil telles que l’adresse IP et les identifiants uniques, ainsi que les données d’utilisation relatives à l’interaction avec la boutique.

Les sources sont de deux ordres : les indications fournies directement par les clientes et clients – lors de la création du compte, de l’achat ou d’une demande – et les données capturées automatiquement via l’offre et l’appareil. Ces deux voies doivent être clairement distinguées dans la déclaration.

Selon la boutique, d’autres types de données s’ajoutent : données d’inventaire, données de paiement, données de localisation, données de contenu, données contractuelles, données d’utilisation, métadonnées, données de communication et de procédure, ainsi que données de journalisation. Pour les applications propres, peuvent s’ajouter des images et vidéos, un historique de localisation, des profils de mouvement ou des données événementielles (Facebook). La déclaration ne mentionne que ce que la boutique traite effectivement.

Les cookies nécessitent une section dédiée : quelles catégories sont utilisées, dans quel but et comment les utilisatrices et utilisateurs peuvent les gérer.

L’étendue dépend des fonctionnalités : analyse web, monitoring et optimisation, marketing en ligne, newsletter, notifications push, services de messagerie instantanée, plug-ins et intégrations. S’y ajoutent le Single Sign-On et l’acquisition d’applications via les app stores. Chaque fonctionnalité reçoit sa propre section.

Pour les comptes utilisateurs, il faut expliquer quelles mentions obligatoires sont collectées lors de l’inscription et à quelle fin ; pour les paiements, préciser quelles données de paiement sont transmises à qui ; pour les demandes de contact, indiquer quelles données du formulaire sont traitées et combien de temps elles sont conservées.

L’étendue de la collecte doit correspondre à la LPD : celui qui n’a besoin des données clients que pour le traitement des commandes, l’expédition et le support ne définit pas la finalité plus largement et ne collecte pas de données par anticipation. La déclaration décrit l’exploitation réelle et est régulièrement actualisée.

La déclaration s’enrichit avec l’étendue fonctionnelle : chaque moyen de paiement, chaque newsletter et chaque application obtient sa section avant sa mise en ligne. Les sections sans traitement effectif sont supprimées.

Les déclarations portent une date de version : SIGG indique le 16 juin 2026, calimoto le 21 juillet 2025. Cette date montre quand le texte a été actualisé pour la dernière fois.

Les mentions légales, les conditions générales de vente et la déclaration de confidentialité sont des documents distincts dans les boutiques en ligne. En cas de contradiction entre les conditions d’utilisation et la déclaration de confidentialité concernant la collecte, le traitement et la divulgation de données personnelles, la déclaration de confidentialité peut primer ; SIGG règle expressément cette primauté.

Transferts internationaux de données et collaboration avec des prestataires

En pratique, l’hébergement, le traitement des paiements et l’analyse résident rarement exclusivement en Suisse. Lorsque des données personnelles sont transmises à des prestataires ayant leur siège ou leurs serveurs à l’étranger, il s’agit d’un transfert de données à l’étranger qu’il convient de sécuriser.

Une protection adéquate des données peut être assurée au moyen de clauses contractuelles types approuvées, établies ou reconnues au préalable par le PFPDT. Elles fondent contractuellement les transmissions, sans qu’il soit nécessaire de concevoir une solution spécifique pour chaque cas individuel. La collaboration avec les prestataires intégrés doit être clairement documentée.

Dans la chaîne technique, ce sont généralement les mêmes points où les données quittent le pays : l’hébergement web, le traitement des paiements et l’analyse web. Celui qui documente la localisation, les sous-traitants et la suppression pour ces trois prestataires couvre la majeure partie des transmissions.

Dans la déclaration de confidentialité, il faut mentionner les destinataires, les catégories de destinataires et les pays de traitement. En interne, un catalogue contractuel précise avec quel prestataire quel accord existe et quelles données sont transmises.

Dans les déclarations, les transferts ont leur propre section. ETA EXTENSIONS et calimoto indiquent « Transferts internationaux de données », à côté figure « Transmission de données personnelles ».

Lors du choix des prestataires, les mêmes questions valent la peine : où les données sont-elles hébergées, quels sous-traitants sont utilisés, quelles mesures de sécurité existent, et comment la suppression est-elle effectuée ?

Si un prestataire change ou déplace ses serveurs, la transmission est réévaluée. Le catalogue contractuel est actualisé à chaque changement de prestataire.

Accessibilité : obligations en Suisse et dans l’UE

En Suisse, la LHand et l’OHand constituent les bases légales de l’accessibilité numérique. Elles s’adressent notamment aux organismes publics, en premier lieu au niveau fédéral ; les cantons et les communes suivent les prescriptions cantonales applicables. Pour les entreprises privées, il n’existe aucune obligation générale de respecter les WCAG pour tous les sites web.

Reste pertinent l’interdiction de défavoriser quiconque dans l’accès aux prestations de service offertes au public. Une boutique qui rend de facto l’utilisation impossible pour une cliente ou un client risque de se retrouver impliquée dans un litige juridique.

La situation diffère pour les activités dans l’UE. L’European Accessibility Act (EAA) est une directive européenne de 2019, qui devait être transposée dans tous les États membres de l’UE d’ici juin 2025. Elle exige, entre autres, que les offres de commerce électronique – sites web et applications mobiles de boutiques en ligne – soient conçues de manière accessible d’ici au 28 juin 2025.

Tous les éléments de l’expérience d’achat sont concernés : navigation, informations produit, processus de commande et de paiement. Les États membres n’ont pas prévu d’exemptions générales pour les petites boutiques. Dans certains pays, des exemptions s’appliquent aux microentreprises ; fondamentalement, la réglementation vise tous les fournisseurs commerciaux s’adressant aux consommateurs.

Pour les entreprises suisses de e-commerce : celles qui opèrent principalement sur le marché intérieur suivent les prescriptions suisses. Celles qui servent une clientèle dans l’UE, ou envisagent de le faire, sont concernées par l’EAA. En Allemagne, la loi sur le renforcement de l’accessibilité (BFSG) s’applique depuis le 28 juin 2025 à certains produits et services numériques, y compris le e-commerce. D’autres pays de l’UE ont leurs propres transpositions.

Au Liechtenstein, l’EAA n’avait pas encore été pleinement intégré au droit de l’EEE en septembre 2026.

Les trois pays réglementent la matière différemment. Au Liechtenstein, des exigences légales s’appliquent aux sites web et applications des organismes publics ; en Allemagne, pour les organismes publics, la BGG et la BITV 2.0, ou le droit cantonal. Les bases légales portent des noms différents selon le pays : LHand et OHand en Suisse, BGlG au Liechtenstein, BGG, BITV 2.0, BFSG et BFSGV en Allemagne.

Pour la planification, le marché de vente réel compte : si la boutique ne vend qu’en Suisse, la situation de départ diffère de celle d’une entreprise avec envoi transfrontalier et comptes clients dans l’UE. La direction reste la même dans les deux cas – l’accessibilité est obligatoire pour les activités dans l’UE et constitue en Suisse un critère d’utilisabilité.

Pour la mise en place, cela signifie : celui qui ne vend qu’en Suisse planifie l’accessibilité comme objectif d’utilisabilité ; celui qui vend dans l’UE la planifie comme une obligation avec la date butoir du 28 juin 2025.

Mise en œuvre accessible : WCAG, eCH-0059 et EN 301 549

Pour la mise en œuvre technique, trois références sont centrales. Les WCAG (Web Content Accessibility Guidelines) décrivent les exigences de contenu. En Suisse, eCH-0059 est la norme importante pour l’accessibilité des sites web et des applications mobiles. Elle s’appuie techniquement sur le niveau de conformité AA des WCAG 2.1 et s’applique en version 3.0 pour la Confédération.

Dans le contexte européen, EN 301 549 est la référence technique harmonisée. En Allemagne, la référence juridique actuelle renvoie à la version 3.2.1 et donc aux WCAG 2.1 AA. Depuis septembre 2026, la version 4.1.1 est publiée, prenant en compte les WCAG 2.2.

Les références sont versionnées, et les versions divergent. eCH-0059 V3.0 s’applique à la Confédération. Dans les contextes proches de la Suisse et au Liechtenstein, la référence harmonisée s’applique en version 3.2.1 avec WCAG 2.1 AA.

L’EAA formule des exigences fonctionnelles qui s’orientent vers des directives établies comme les WCAG 2.1 AA.

Trois principes guident cette démarche. Utilisabilité : la navigation et le contrôle doivent être possibles avec tous les dispositifs d’entrée usuels – entièrement au clavier ou via un lecteur d’écran, pas seulement à la souris. Perceptibilité : les contenus doivent être lisibles et visuellement clairs, avec des contrastes suffisants et des tailles de police ajustables. Compréhensibilité : les informations doivent être formulées simplement et clairement, en évitant un langage complexe.

Transposé à la boutique, cela concerne tous les domaines centraux. La navigation principale et la recherche de produits doivent être utilisables sans souris, avec un focus visible et des libellés clairs pour les technologies d’assistance.

Les informations produit nécessitent des textes alternatifs pour les images, une structure correcte des titres et des tableaux ; les indications de prix doivent être lisibles sous forme de texte, pas uniquement sous forme graphique. Dans le checkout, les champs de formulaire doivent être clairement étiquetés, les messages d’erreur compréhensibles et la progression identifiable. Les applications mobiles suivent les mêmes principes.

L’accessibilité ne concerne pas seulement la page d’accueil. Justement le panier, la saisie d’adresse et le paiement décident si un achat peut être finalisé. Pour les sites web et les applications mobiles, eCH-0059 prévoit également une déclaration d’accessibilité documentant l’état de mise en œuvre.

Pour le choix du niveau cible, la situation propre est déterminante : celui qui sert une clientèle UE s’oriente vers les références exigées là-bas ; pour le marché suisse, eCH-0059 et les WCAG 2.1 AA offrent une base reconnue.

Dans la mise en place, cela signifie : la bibliothèque de composants et le checkout sont construits une fois de manière accessible, puis réutilisés dans chaque nouvelle fonctionnalité.

Accessibilité dès le début : concept, design, code, tests

L’accessibilité ne peut pas être appliquée a posteriori sur un site web. Elle doit être pensée dès le début : dans le concept, le design, l’architecture, le code et les tests. Celui qui ne vérifie que peu avant le lancement doit s’attendre à des corrections plus lourdes et plus coûteuses.

Dans le concept, il s’agit des scénarios d’utilisation : qui utilise la boutique, avec quels appareils, moyens de saisie et limitations ? Dans le design, comptent les contrastes, la typographie, les états de focus, les étiquettes de formulaire et les messages d’erreur. Dans l’architecture et le code, comptent la structure sémantique, des composants avec des états clairs et une bibliothèque qui fournit des blocs accessibles comme standard.

Lors des tests, les outils de vérification automatisés sont insuffisants. Ils détectent une partie des problèmes techniques, comme l’absence de textes alternatifs ou des contrastes insuffisants, mais pas si une navigation est compréhensible ou si un lecteur d’écran lit le processus de commande de manière sensée. Des vérifications manuelles au clavier et avec un lecteur d’écran sont donc nécessaires, ainsi que, si possible, des tests avec des personnes utilisant des technologies d’assistance au quotidien.

Pour l’exploitation courante, l’accessibilité fait partie de la « Definition of Done » des nouvelles fonctionnalités et de la répétition régulière des vérifications. Chaque nouveau filtre, chaque nouveau moyen de paiement et chaque révision du design peuvent détériorer l’accessibilité existante.

Pour la mise en place, il en résulte : l’accessibilité fait partie des exigences adressées à l’agence et à l’équipe de développement, pas d’une phase de contrôle ultérieure.

Normes et standards pour le marché suisse

La Société suisse de normalisation (SNV) représente la normalisation mondiale (ISO) et européenne (CEN) et agit au profit de l’économie et de la société suisses. Elle favorise le développement et l’harmonisation des normes et permet à plus de 2'000 spécialistes suisses de participer activement au processus national et international de normalisation. Elle est structurée en sept domaines spécialisés : domaine interdisciplinaire des normes, industrie des machines, électrique et métallurgique, construction, routes et trafic, industrie horlogère, électrotechnique et télécommunications.

Les sept domaines spécialisés portent leurs propres sigles. INB pour le domaine interdisciplinaire des normes, SWISSMEM pour l’industrie des machines, électrique et métallurgique, SIA pour la construction et VSS pour les routes et le trafic. FH pour l’industrie horlogère, Electrosuisse pour l’électrotechnique et asut pour les télécommunications.

Les normes sont obtenues via la boutique de normes SNV-Connect. On y trouve les produits des organisations nationales et internationales de normalisation, parmi lesquels on peut sélectionner le jeu approprié.

Pour les exploitants de boutiques, les normes sont surtout le langage commun entre le donneur d’ordre, l’agence, l’équipe de développement et l’organisme de contrôle. Celui qui renvoie à des standards reconnus dans l’appel d’offres rend les résultats comparables, au lieu de débattre de questions de goût.

Dans le domaine de l’accessibilité, eCH-0059 est la référence suisse : la norme est contraignante pour la Confédération et suit techniquement les WCAG 2.1 au niveau AA ; elle prévoit, entre autres, une déclaration d’accessibilité pour les sites web et les applications mobiles.

Au niveau international, EN 301 549 constitue la référence européenne harmonisée, à laquelle se rapportent les exigences dans l’espace UE. Celui qui connaît les deux peut documenter la même boutique pour le marché suisse et le marché UE, sans devoir maintenir deux systèmes séparés.

Les références et versions font partie de la réception : eCH-0059 V3.0 pour la Confédération, EN 301 549 version 3.2.1 dans le contexte UE et la version 4.1.1 publiée depuis septembre 2026 avec WCAG 2.2. Celui qui nomme la version dans le contrat vérifie ensuite sur la même base.

Références légales et techniques importantes

Exploitation : sécurité, durée de conservation et suppression

L’exploitation est le troisième domaine de la mise en place : elle commence avec le lancement et se poursuit ensuite. Elle englobe la sécurité, la disponibilité, la maintenabilité et les tâches récurrentes.

L’exploitation courante exige des mesures techniques et organisationnelles proportionnées au risque. Déterminants sont l’état de la technique, les coûts de mise en œuvre, la nature, l’étendue, les circonstances et les finalités du traitement, ainsi que la probabilité d’occurrence et l’ampleur des menaces potentielles pour les droits et libertés des personnes physiques. L’objectif est un niveau de protection approprié : la confidentialité, l’intégrité et la disponibilité des données doivent être assurées.

La sécurisation de la confidentialité, de l’intégrité et de la disponibilité comprend aussi le contrôle de l’accès physique aux systèmes et aux locaux. Cela fait partie des mêmes mesures proportionnées au risque que les rôles et les autorisations.

Les restrictions d’accès en sont un élément central. Qui peut voir et modifier quelles données clients dans la boutique est régi par des rôles et des autorisations, non par l’habitude – tant dans le backend de la boutique que dans les outils d’analyse, de marketing et de support. Chaque accès aux données personnelles doit être limité au nécessaire pour la tâche respective.

Dans les grandes boutiques, les rôles s’appellent Super-Admin, Admin, Rédacteur et Gestionnaire de boutique, répartis sur de nombreux produits. Celui qui définit ces rôles tôt peut ajuster les autorisations dans le backend de la boutique en conséquence.

La durée de conservation implique un concept de suppression. Les déclarations de confidentialité contiennent généralement une section dédiée avec des informations générales sur la conservation et la suppression des données ; il y est indiqué quand les données sont supprimées ou anonymisées.

Dans l’exploitation, cela signifie : définir un délai de conservation pour chaque catégorie de données, l’appliquer techniquement – par exemple via des procédures automatisées de suppression – et documenter la suppression de manière traçable. Lorsque des obligations légales de conservation s’opposent à une suppression immédiate, le traitement ultérieur est limité à cette finalité.

La déclaration de confidentialité comporte une section propre aux mesures de sécurité. Elle décrit quelles mesures techniques et organisationnelles la boutique met en œuvre et comment un niveau de protection proportionné au risque est atteint.

L’analyse web, le monitoring et l’optimisation accompagnent l’exploitation. Ils doivent être conduits comme un traitement distinct avec sa propre finalité et mentionnés séparément dans la déclaration.

Des plateformes comme Shopify répartissent l’exploitation entre le fournisseur et l’exploitant. Celui qui gère la boutique là-bas clarifie contractuellement les mises à jour, la gestion des clés et les procédures de suppression, et fixe quelles tâches restent à la charge de l’exploitant.

Les données de journalisation constituent un type de données propre à l’exploitation. Elles naissent lors de l’utilisation de l’offre, servent à la sécurité et doivent être listées dans la déclaration parmi les types de données.

En cas de violation de la protection des données, une procédure claire est nécessaire, indiquant qui décide en interne et comment agir.

S’y ajoutent les tâches récurrentes : mises à jour du logiciel de boutique et des bibliothèques, gestion des clés et des données d’accès, journalisation des événements liés à la sécurité et une procédure claire en cas de violation de la protection des données.

Le droit, la technique et l’exploitation se rencontrent dans les délais : le délai de conservation vient du droit, la procédure de suppression de la technique, le contrôle de l’exploitation. Celui qui conduit ensemble rôles, délais et procédures de suppression maintient la boutique traçable.

Liste de contrôle pour le démarrage

Cette liste de contrôle couvre les trois domaines de la mise en place : droit, technique et exploitation. Elle commence par le droit, passe par les composants techniques et se termine par les routines d’exploitation.

Protection des données : Nommer le responsable du traitement avec adresse et point de contact dans la déclaration de confidentialité. Établir un registre des traitements et attribuer à chaque catégorie de données une finalité reconnaissable, compatible avec le traitement. Respecter la bonne foi, la licéité et la proportionnalité ainsi que la limitation de la finalité selon l’art. 6 LPD.

Déclaration de confidentialité : Prévoir des sections sur l’hébergement, les procédés de paiement, les cookies, l’inscription et le compte utilisateur, la gestion des contacts et des demandes, ainsi que – le cas échéant – sur les applications mobiles. Indiquer les types de données, les sources, les destinataires, les pays et la durée de conservation. Aligner régulièrement la déclaration et l’exploitation réelle.

Responsable du traitement : Indiquer le nom, l’adresse et le point de contact du responsable du traitement dans la déclaration. Si nécessaire, mentionner un délégué à la protection des données avec adresse et adresse e-mail dédiée.

Fonctionnalités : Prévoir une section distincte pour l’analyse web, le monitoring et l’optimisation, le marketing en ligne, les newsletters et notifications push, les services de messagerie instantanée, les plug-ins et intégrations, le Single Sign-On ainsi que l’acquisition d’applications via les app stores.

Transferts internationaux : Vérifier pour chaque prestataire à l’étranger quelles données sont transmises. Sécuriser les transmissions avec des clauses contractuelles types approuvées, établies ou reconnues au préalable par le PFPDT.

Technique : Définir le système de boutique, l’hébergement web, le traitement des paiements et l’analyse web comme composants distincts et les articuler entre eux. Pour le système de boutique, préciser quelles tâches d’exploitation la plateforme assume et lesquelles restent à la charge de l’exploitant. Documenter pour l’hébergement web et l’analyse la localisation des données, les sous-traitants et la suppression.

Système de boutique : Distinguer entre les systèmes pour les grandes entreprises avec de nombreux produits et rôles – Oracle Commerce Cloud, IBM WebSphere Commerce, SuiteCommerce d’Oracle NetSuite, SAP Commerce Cloud, Sitecore Experience Commerce, Intershop Commerce Suite, SAP Hybris Commerce, Salesforce Commerce Cloud – et les systèmes pour les PME. Vérifier ce que signifie concrètement « SEO ready ».

Systèmes PME : Pour les PME, examiner des systèmes comme Plenty, pris en charge par des agences digitales et des webdesigners locaux. Confronter la liste des fonctionnalités prioritaires aux fonctions réellement proposées avant le choix.

Données de paiement : Ne collecter les informations de carte et de compte, les détails des transactions et la confirmation de paiement que dans la mesure nécessaire au traitement des commandes. Indiquer dans la déclaration de confidentialité quelles données de paiement sont transmises à qui.

Documents : Tenir séparément la déclaration de confidentialité, les conditions générales de vente et les mentions légales. En cas de contradictions entre les conditions d’utilisation et la déclaration de confidentialité, clarifier la primauté lors de la collecte, du traitement et de la divulgation de données personnelles.

Accessibilité Droit : Clarifier si la boutique sert une clientèle UE – alors les prescriptions de l’EAA s’appliquent avec la date butoir du 28 juin 2025 pour les sites web et les applications mobiles de boutiques en ligne. Sur le marché intérieur, respecter les prescriptions pour les organismes publics selon la LHand/OHand et prendre en compte l’interdiction de discrimination dans le commerce des services. En Allemagne, le BFSG doit être pris en compte depuis le 28 juin 2025.

Accessibilité Technique : Mettre en œuvre les WCAG 2.1 AA comme base technique, respecter eCH-0059 comme référence suisse et prendre en compte EN 301 549 pour les activités dans l’UE. Rendre la navigation entièrement utilisable au clavier, vérifier les contrastes et les tailles de police, garder un langage simple. Pourvoir les images de textes alternatifs, les formulaires d’étiquettes claires et de messages d’erreur compréhensibles. Traiter le checkout, les pages produit et les applications mobiles comme la page d’accueil.

Accessibilité Processus : Ancrer les exigences dans le concept, le design, l’architecture, le code et les tests. Compléter les vérifications automatisées par des tests manuels au clavier et avec un lecteur d’écran, et intégrer l’accessibilité dans la « Definition of Done ». Préparer une déclaration d’accessibilité selon eCH-0059 pour le site web et l’application.

Normes : Renvoyer à des standards reconnus dans les appels d’offres et les réceptions. Distinguer entre la référence suisse (eCH-0059) et la référence européenne (EN 301 549) et documenter les résultats en conséquence. Acquisition via la boutique de normes SNV-Connect.

Exploitation : Définir des mesures de sécurité techniques et organisationnelles proportionnées au risque et assurer la confidentialité, l’intégrité et la disponibilité des données. Définir des rôles et des autorisations pour chaque accès aux données clients. Fixer un délai de conservation pour chaque catégorie de données, mettre en place des procédures automatisées de suppression et documenter la suppression. Planifier des mises à jour récurrentes, la gestion des clés, la journalisation et une procédure en cas de violation de la protection des données.

Violation de la protection des données : Prévoir une procédure fixant la responsabilité interne et la marche à suivre.

Sécurité et journaux : Tenir une section sur les mesures de sécurité et traiter les données de journalisation comme un type de données distinct. Maintenir une date de version dans la déclaration et actualiser le texte.

Standards : Distinguer eCH-0059 V3.0 pour la Confédération, EN 301 549 en version 3.2.1 dans le contexte UE et la version 4.1.1 depuis septembre 2026 avec WCAG 2.2.

Routines d’exploitation : Les mises à jour du logiciel de boutique et des bibliothèques, la gestion des clés et des données d’accès, la journalisation des événements liés à la sécurité et une procédure claire en cas de violation de la protection des données font partie de l’exploitation dès le premier jour.

En résumé : Le droit comprend la LPD, la LHand et l’OHand ; pour les activités dans l’UE l’EAA, en Allemagne le BFSG, la BGG, la BITV 2.0 et la BFSGV, au Liechtenstein la BGlG. La technique comprend eCH-0059, WCAG 2.1 AA, EN 301 549, des systèmes de boutique comme Shopify ou Plenty, ainsi que l’hébergement web, le traitement des paiements et l’analyse web. L’exploitation comprend les mises à jour, la gestion des clés, la journalisation et les procédures automatisées de suppression.