7 erreurs de bannière cookies qui peuvent coûter cher aux PME suisses

Au cours des 18 derniers mois, j'ai examiné environ 150 sites suisses pour leur conformité bannière cookies. Sept erreurs se présentent si régulièrement qu'elles peuvent être clairement identifiées. Voici la liste — avec proposition de correction concrète qui ne rend pas la bannière plus intrusive, mais juridiquement du côté sûr.

Erreur 1 — « Accepter » plus grand que « Refuser »

Le classique. Bouton Accepter : grand, vert lumineux, visible. Bouton Refuser : petit, gris, semi-transparent, parfois juste un lien texte.

Pourquoi c'est un problème : le guide PFPDT V1.1 exige explicitement l'équivalence. Conforme RGPD seulement quand les deux boutons sont visuellement comparables. L'inégalité est considérée comme un dark pattern.

Correction : les deux boutons même taille, même contraste, même position. Si vous craignez l'impact sur la conversion — ne vous inquiétez pas, en pratique je vois chez les clients Aiara plutôt des taux d'acceptation plus élevés car la confiance augmente.

Erreur 2 — Cases pré-cochées

La page détail de la bannière montre les catégories (statistiques, marketing) comme toggles — et ils sont activés par défaut. L'utilisateur devrait désactiver manuellement.

Pourquoi c'est un problème : un consentement préréglé n'est pas un consentement libre. Clairement interdit sous RGPD. Problématique sous LPD.

Correction : tous les toggles désactivés par défaut. Activation seulement avec clic explicite. Les cookies nécessaires restent (techniquement) actifs et ne peuvent pas être désactivés — c'est légitime.

Erreur 3 — Cookies marketing chargés avant consentement

Vous ouvrez le site, la bannière apparaît, et pendant que vous lisez encore — Google Ads, Meta Pixel et Hotjar chargent déjà. La bannière est pure décoration.

Pourquoi c'est un problème : quand les cookies sont posés avant consentement, le consentement est insensé. C'est l'erreur la plus grave parmi les fréquentes.

Correction : ajuster la logique Tag Manager. Scripts de tracking avec déclencheur de consentement. Avec implémentation correcte, rien de trackant ne charge avant que l'utilisateur n'ait activement consenti. La bannière Aiara bloque les scripts marketing par défaut.

Erreur 4 — Pas d'adaptation spécifique au domaine

Les agences web utilisent le même code de bannière pour tous les sites clients. La bannière liste donc des cookies qui ne tournent pas sur ce site concret — ou au contraire, ne nomme pas des cookies existants.

Pourquoi c'est un problème : la politique de confidentialité ne correspond pas au traitement de données effectif. Lors d'un contrôle aléatoire, c'est une violation documentée.

Correction : par site, un scan cookie propre qui détecte les cookies effectivement posés. Bannière et politique de confidentialité générées sur cette base. Aiara le fait automatiquement — à l'ajout d'un domaine, le scanner tourne et la bannière est configurée en conséquence.

Erreur 5 — Documentation obsolète

La configuration de la bannière a été faite en 2022, jamais adaptée depuis. Entre-temps, trois nouveaux outils ont été intégrés (HubSpot, un nouveau service de newsletter, un embed Vimeo). La politique de confidentialité ne les mentionne pas.

Pourquoi c'est un problème : lors d'une demande d'accès, il doit être clair quelles données vont à quels destinataires. Une documentation obsolète rend cela impossible.

Correction : scan automatique trimestriel plus revue trimestrielle de la politique. Chez les clients Aiara c'est intégré — le scan tourne mensuellement, les écarts sont signalés.

Erreur 6 — Journal de consentement manquant

La bannière montre accepter/refuser, mais personne ne tient un registre de qui a choisi quoi quand. Lors d'une demande d'accès, rien ne peut être prouvé.

Pourquoi c'est un problème : la charge de la preuve incombe au responsable. Qui n'a pas de documentation de consentement est considéré comme n'ayant pas de consentement.

Correction : journal de consentement avec horodatage, hash IP (ou autre identifiant pseudonyme) et catégories choisies. Aiara consigne cela par défaut — lors d'une demande d'accès, vous exportez les enregistrements en un clic.

Erreur 7 — Test mobile manquant

La bannière paraît bien sur desktop. Mais sur mobile : elle couvre 80 % de l'écran, le bouton refuser n'est pas visible, ou la bannière ne disparaît pas.

Pourquoi c'est un problème : 60 % des visites de sites suisses viennent du smartphone. Une bannière non fonctionnelle sur mobile concerne la majorité des utilisateurs.

Correction : tester la bannière sur de vrais appareils mobiles — pas seulement dans la vue mobile DevTools. La bannière Aiara est conçue responsive, testée sur iOS Safari, Android Chrome et versions mobiles d'Edge.

Checklist d'auto-audit

Vous pouvez vérifier votre propre bannière en 10 minutes :

1. Boutons équivalents ? (Au premier coup d'œil, les deux ressortent-ils également ?)
2. Toggles désactivés par défaut ? (Ouvrir page détail, vérifier)
3. Tracking seulement après clic ? (DevTools → Network, avant et après clic sur Accepter)
4. Cookies correspondent à la politique ? (Application → Cookies comparer avec politique)
5. Date de mise à jour de la politique inférieure à 6 mois ?
6. Journal de consentement présent ? (Demander au prestataire)
7. Test mobile ? (Vrai smartphone, pas émulation navigateur)

Ce qu'Aiara couvre concrètement ici

Chez Aiara, ces sept erreurs sont adressées par défaut. Boutons équivalents, toggles désactivés par défaut, scripts marketing seulement après consentement, scan cookie spécifique au domaine, mise à jour mensuelle de la politique, journal de consentement intégré, bannière optimisée mobile. Ce n'est pas de la magie — c'est l'implémentation propre de ce que LPD, RGPD et guide PFPDT exigent depuis des années. Les agences web utilisant Aiara peuvent dire sérieusement à leurs clients : « Le volet bannière est désormais propre. » Et le penser sincèrement.