Comment encadrer les outils tiers du site avec votre modèle DPA
et configurer la bannière cookies?

Un site WordPress moderne charge couramment une dizaine de scripts tiers — Google Analytics, polices web, vidéos intégrées, passerelle de paiement, infolettre, outil de réservation. Chacun de ces scripts est un sous-traitant au sens de la Loi 25, qui voit passer des renseignements personnels (au minimum l'adresse IP du visiteur) et qui doit être encadré par un DPA. Cet atelier applique le modèle DPA construit en partie 2 à ces outils, puis configure une bannière cookies qui respecte le principe : informer avant de charger.

Pour la théorie de base — référez-vous d'abord à

Ce que vous apportez à l'atelier

L'entrée de cet atelier est un livrable précis construit dans la formation Mise en place gouvernance partie 2 : le modèle de DPA (entente de traitement avec sous-traitant) — document contractuel type qui décrit les obligations du sous-traitant en matière de finalité, confidentialité, sécurité, sous-traitance ultérieure, durée, restitution, notification d'incident et localisation des données.

Si vous arrivez sans ce livrable, commencez par le module Sous-traitants et DPA — la démarche de cet atelier suppose que le modèle existe déjà.

La démarche concrète — étape par étape

Voici la séquence transmise pendant l'atelier, illustrée sur le cas-modèle d'une PME québécoise (entreprise électricienne avec site WordPress comportant une page de présentation, un formulaire de contact, une page de demande de soumission et une inscription à l'infolettre). Vous adaptez ensuite à votre propre site.

Étape 1 — Inventorier les scripts tiers réellement chargés

Ouvrez votre site dans un navigateur et utilisez l'inspecteur (clic droit → Inspecter → onglet Réseau) pour lister tous les domaines tiers contactés au chargement d'une page. Sur le cas-modèle, vous trouverez typiquement :

• Google Fonts (polices web) — google.com / gstatic.com
• Google Analytics ou équivalent — google-analytics.com
• YouTube intégré sur une page projet — youtube.com
• Service d'infolettre (Mailchimp, Sendinblue, ConvertKit) — mailchimp.com, etc.
• Google reCAPTCHA si formulaire protégé — google.com
• Pixel publicitaire éventuel (Meta, LinkedIn) — facebook.com

Ne pas oublier les scripts côté serveur non visibles dans l'inspecteur : intégration CRM via webhook, antispam serveur, etc. Le registre étendu de l'atelier 1 vous aide à ne rien oublier.

Étape 2 — Classer chaque outil par catégorie de consentement

Tous les outils tiers ne déclenchent pas la même obligation. Trois catégories :

• Techniques strictement essentiels — antispam, cookie de session, équilibrage de charge. Pas de consentement requis, mais à documenter dans la politique publique.
• Analytique et statistiques — Google Analytics et équivalents. Consentement requis en RGPD, info + retrait simple en Loi 25 (la nuance est importante si trafic UE).
• Marketing, médias intégrés, traceurs publicitaires — pixels Meta/LinkedIn, vidéos YouTube non bloquées, infolettre avec traceur d'ouverture. Consentement explicite requis avant tout dépôt de cookie.

Étape 3 — Vérifier le DPA fourni par chaque fournisseur

Les grands fournisseurs publient leur propre DPA standard — Google (« Google Cloud Data Processing Addendum »), Stripe (« DPA »), Mailchimp (« Data Processing Addendum »). Pour chacun, vérifiez :

• La localisation des données et les transferts hors Québec (souvent vers les États-Unis ou l'Union européenne)
• La présence de clauses contractuelles types ou d'un mécanisme équivalent pour ces transferts
• Le délai de notification d'incident au responsable du traitement
• Les droits d'audit et les obligations de sous-traitance ultérieure (le sous-traitant peut-il déléguer à un autre acteur?)

Outils transmis dans l'atelier : une grille d'évaluation rapide pour cocher ces points sur les DPA fournisseurs courants.

Étape 4 — Appliquer votre modèle DPA aux outils sans DPA standard

Pour les outils qui n'offrent pas de DPA standard (petits fournisseurs locaux, agences, plateformes spécialisées), vous appliquez le modèle DPA construit en partie 2. La démarche : envoyer votre modèle au fournisseur, négocier les écarts (en général la durée de notification d'incident et les droits d'audit), faire signer. Si le fournisseur refuse de signer un DPA et qu'aucune équivalence n'est documentée, la Loi 25 considère le traitement comme non encadré — c'est un signal d'alerte sérieux.

Étape 5 — Configurer la bannière cookies conforme

Une bannière cookies n'est pas qu'un bandeau visuel — c'est un dispositif technique qui doit respecter quelques principes non négociables :

• Granularité — pas un seul bouton « tout accepter » ; au moins trois choix (essentiels, analytique, marketing) avec acceptation ou refus par catégorie
• Ordre de chargement — la bannière s'affiche avant que les scripts non essentiels ne soient chargés ; un script chargé avant le consentement a déjà déposé son cookie
• Symétrie visuelle — le bouton « refuser » est aussi visible que le bouton « accepter » (pas un lien minuscule en gris)
• Mécanisme de retrait — accessible à tout moment depuis le pied de page (« Gérer mes préférences cookies »), avec effet immédiat
• Journal du consentement — la date et la version du consentement de chaque visiteur sont conservées pour pouvoir prouver la conformité en cas d'enquête

Étape 6 — Inscrire chaque outil au registre et planifier la revue

Chaque outil tiers validé entre dans le registre étendu construit à l'atelier 1, avec son DPA (lien ou copie), sa catégorie de consentement, sa localisation de données. La revue annuelle systématique du registre couvre alors automatiquement les outils tiers — pas besoin d'un processus séparé. Quand un nouvel outil est ajouté au site entre-temps, la démarche est : DPA → registre → bannière → mise en ligne. Jamais l'inverse.

Outils et gabarits transmis pendant l'atelier

• Grille d'évaluation des DPA fournisseurs — colonnes type (fournisseur, lien DPA, localisation des données, transferts hors Québec, délai notification incident, sous-traitance ultérieure).
• Principes de configuration de la bannière cookies — granularité, ordre de chargement, symétrie visuelle, mécanisme de retrait, journal du consentement.
• Liste de validation à vérifier avant mise en ligne — un script chargé avant la bannière est un bug bloquant.
• Procédure d'ajout d'un nouvel outil tiers — DPA → registre → bannière → mise en ligne, dans cet ordre.

Ces outils sont à appliquer ensuite, à votre rythme, sur votre propre inventaire d'outils tiers et votre propre bannière. L'atelier transmet la méthode sur le cas-modèle ; l'application complète à votre organisation se fait après la formation.

🌐 Dimension internationale

Les exigences applicables à la bannière cookies divergent fortement selon les régimes :

• Loi 25 (Québec) — information claire au moment du chargement + mécanisme de retrait simple. Pas d'exigence stricte de consentement granulaire pré-dépôt, mais bonne pratique reconnue.
• RGPD (Union européenne) — consentement explicite et granulaire obligatoire avant tout dépôt de cookie non essentiel. Une case pré-cochée n'est pas un consentement valide. Le bouton « refuser » doit être aussi visible que « accepter ».
• CCPA / CPRA (Californie) — droit à l'opt-out de la vente de données, mécanisme « Do Not Sell or Share My Personal Information » accessible depuis chaque page.

Stratégie pratique : si votre clientèle est exclusivement québécoise, Loi 25 suffit. Si vous avez du trafic international (l'analytique le confirme), adoptez la position la plus stricte commune — consentement explicite granulaire pré-dépôt, façon RGPD — ou géolocalisez l'affichage de la bannière selon l'IP du visiteur. Les transferts vers les États-Unis pour les visiteurs UE sont un point de vigilance particulier à intégrer aux DPA. Pour la base conceptuelle multi-régimes, voir la formation Initiation aux normes internationales.

Pièges à éviter lors de la transposition

En résumé

Cet atelier 2 ne vous redonne pas la théorie du Bloc 1 site web — il vous donne la démarche pour partir de votre modèle DPA existant et l'appliquer aux scripts tiers du site, plus les principes de configuration d'une bannière cookies conforme. Les ateliers suivants convertissent la politique interne en politique publique, puis rendent le RPRP visible et activent la grille EFVP avant chaque nouvel outil web.