Depuis des années, la règle était simple : avant d’envoyer un email client à Google Ads, on le passe à la moulinette SHA-256. Le 16 novembre 2026, le hachage SHA-256 Google Ads devient facultatif : Data Manager accepte par défaut des données chiffrées, qu’il déchiffre lui-même pour les rapprocher de ses comptes. Promesse affichée : un meilleur taux de correspondance. Question que personne ne pose dans l’annonce : qu’est-ce que vos pipelines, votre registre RGPD et votre DPO ont à en dire ? Voici ce qui change vraiment, ce que Google ne dit pas encore, et comment décider flux par flux sans rien casser à moins de deux semaines du Black Friday.
Le cadre habituel : je décris la mécanique et ce que Google annonce. Choisir d’envoyer des identifiants en clair ou non, et sur quelle base, c’est une décision à prendre avec votre DPO.
Ce qui change le 16 novembre 2026 (et ce que Google ne dit pas)
Le contenu de l’email de Google
L’information vient d’un email envoyé par Google aux utilisateurs de Data Manager, partagé sur LinkedIn par Anthony Higman (ADSQUIRE) et relayé par PPC Land le 18 octobre 2026. Google y écrit qu’il ne requerra plus de données clients hachées en SHA-256, qu’il prendra en charge par défaut des données clients chiffrées, et qu’il les « déchiffre, normalise et rapproche » des données des comptes Google. Justification : une meilleure précision de correspondance grâce à des technologies de protection de la vie privée.
Premier point de prudence : au moment où j’écris, le 9 novembre, aucune page d’aide officielle ne mentionne la date du 16 novembre. Tout ce qui touche à l’échéance repose sur l’email, relayé par la presse spécialisée (PPC Land, SHM Studio), pas encore sur la documentation de Google.
Les flux concernés
D’après les relais de l’email, le changement couvre les deux usages qui consomment des données clients dans Google Ads, par les quatre voies d’entrée de Data Manager :
| Usage | Ce qui part chez Google | Voies concernées |
|---|---|---|
| Customer Match | listes de clients (email, téléphone, nom, adresse) | connexion CRM, stockage cloud, fichier importé, Data Manager API |
| Enhanced conversions et conversions hors ligne | identifiants rattachés à une conversion | connexion CRM, stockage cloud, fichier importé, Data Manager API |
Si vous n’utilisez ni Customer Match ni d’import de conversions via Data Manager, vous n’êtes pas concerné directement. Si vous ne savez pas, c’est le moment de faire l’inventaire : mon guide Google Ads Data Manager détaille les sources qu’il sait brancher.
Les zones d’ombre
L’email laisse plusieurs questions sans réponse, et elles comptent :
- Les uploads déjà hachés. « Ne plus exiger » n’est pas « refuser ». Rien n’indique que vos fichiers hachés seront rejetés, mais Google ne confirme pas non plus qu’ils seront traités exactement comme avant, ni avec quel taux de correspondance.
- Un opt-out. L’email ne décrit aucun réglage pour continuer à n’envoyer que des empreintes.
- Les autres produits. Display & Video 360, Google Analytics et les conversions d’appel ne sont pas mentionnés.
- La durée de vie des données déchiffrées. SHM Studio indique que les données non rapprochées sont supprimées, mais l’email ne détaille ni la journalisation ni la conservation.
Hachage SHA-256 Google Ads, chiffrement, confidential matching : les différences
Ce que le hachage protégeait vraiment
Le hachage SHA-256 transforme [email protected] en une empreinte de 64 caractères, toujours la même pour la même adresse. Google hache ses propres données de la même façon et compare les empreintes. C’est une serrure à sens unique : on ne remonte pas de l’empreinte à l’email.
Sauf que tout le monde peut fabriquer la même empreinte à partir d’une liste d’emails connus. C’est pour ça que la FTC a rappelé dès 2024 que le hachage ne rend pas une donnée anonyme. Au sens du RGPD, un email haché reste une donnée personnelle pseudonymisée. La protection réelle du hachage était plus modeste et plus concrète : l’adresse lisible ne quittait jamais votre système.
L’autre défaut du hachage est opérationnel. Une majuscule oubliée, un espace en fin de chaîne, un point dans une adresse Gmail, et l’empreinte ne correspond plus à rien. Une bonne partie des taux de correspondance décevants vient de là, et c’est exactement ce que Google veut récupérer en normalisant lui-même.
Le TEE et l’attestation, en clair
Le déchiffrement se fait dans un environnement d’exécution de confiance (TEE), le confidential matching. La page d’aide de Google précise qu’il est activé par défaut, sans coût, et construit sur Google Cloud Confidential Space. Imaginez une salle blanche verrouillée : les données y entrent chiffrées, y sont lues, rapprochées, puis seul le résultat en sort. L’attestation, c’est le certificat signé qui prouve quel logiciel tourne dans la salle. Si vous chiffrez vos données, vous pouvez exiger cette attestation avant que la clé ne serve à les déchiffrer.
Détail qui a son importance : la procédure actuelle d’upload chiffré demande encore de formater, hacher en SHA-256, encoder en Base64, puis chiffrer par enveloppe avec une clé que vous détenez dans Cloud KMS. Le chiffrement existait donc déjà, mais par-dessus le hachage. Ce que l’email annonce, c’est de pouvoir sauter l’étape du hachage. Et la documentation ne cite à ce jour que les sources de type fichier (Cloud Storage, SFTP, HTTPS) pour l’upload chiffré : vérifiez le tableau des sources compatibles avant de supposer que votre connecteur suit.
| Hachage seul | Hachage puis chiffrement | Chiffrement sans hachage (16 novembre) | |
|---|---|---|---|
| Ce qui quitte votre système | empreintes | empreintes chiffrées | identifiants lisibles, chiffrés |
| Normalisation | à votre charge | à votre charge | faite par Google |
| Lisible par Google | non, comparaison d’empreintes | non, comparaison d’empreintes | oui, dans le TEE |
| Clé | aucune | vous (Cloud KMS) | selon la configuration retenue |
Vos pipelines : quoi vérifier avant le 16
Connexion CRM et fichiers importés
Pour une connexion native (HubSpot, Salesforce et consorts), le connecteur appartient à l’éditeur ou à Google. Demandez-lui par écrit s’il change de format le 16 novembre et si vous pouvez garder l’envoi haché. Pour les fichiers importés à la main, rien ne vous oblige à modifier votre préparation tant que Google accepte les empreintes : gardez votre script, et notez votre taux de correspondance actuel dans les diagnostics de Data Manager pour avoir un point de comparaison.
BigQuery et stockage cloud
C’est le cas le plus fréquent chez mes clients : une requête planifiée qui prépare la liste dans BigQuery, avec une normalisation maison. Typiquement :
SELECT
TO_HEX(SHA256(LOWER(TRIM(email)))) AS email_sha256
FROM `projet.crm.clients`
WHERE consentement_publicitaire = TRUE
Deux remarques. D’abord, si Google prend la normalisation en charge pour les données non hachées, votre LOWER(TRIM()) ne disparaît pas pour autant tant que vous envoyez des empreintes : c’est lui qui conditionne la correspondance. Ensuite, regardez la clause WHERE. Le vrai sujet RGPD de ce flux, c’est moins la forme de l’email que le fait de n’envoyer que les clients qui ont accepté ce traitement.
Data Manager API et server-side GTM
Si vous alimentez Google Ads par la Data Manager API, relisez la documentation de l’API au moment de la bascule : c’est là que le format chiffré se décrit champ par champ. J’ai comparé l’API au Measurement Protocol dans Measurement Protocol ou Data Manager API, avec ses quotas et son allowlist.
Côté server-side GTM, l’email ne parle pas des tags web. Les Enhanced Conversions en server-side et les Enhanced Conversions for Leads via sGTM continuent de fonctionner comme avant : rien dans l’annonce ne vous demande de toucher à vos tags le 16.
Le volet RGPD : registre, AIPD, information des personnes
Juridiquement, envoyer un email haché ou chiffré, c’est dans les deux cas transmettre une donnée personnelle à Google. Le changement ne crée donc pas un traitement nouveau, mais il peut rendre fausse la description que vous en avez faite. Trois documents à relire :
- Le registre des traitements. S’il indique « seules des empreintes SHA-256 sont transmises » et que vous basculez, il devient inexact.
- L’analyse d’impact (AIPD). Beaucoup d’évaluations de Customer Match s’appuient sur l’idée que l’adresse lisible ne quitte jamais l’annonceur. Si c’est un argument de votre AIPD, il tombe en cas de bascule, et le TEE devient la mesure de sécurité à décrire et à justifier.
- La politique de confidentialité. Elle doit décrire fidèlement ce qui part chez Google. Le passage « vos données sont hachées avant transmission » ne survit pas à un envoi non haché.
Je n’ai trouvé à ce jour aucune prise de position de la CNIL sur ce changement précis. Le raisonnement ci-dessus repose sur les principes généraux : pseudonymisation, exactitude du registre, information des personnes.
Faut-il arrêter de hacher ? La grille de décision par flux
Mon avis : pas le 16 novembre, et pas par réflexe. Le gain de correspondance est plausible, puisque Google corrige lui-même les erreurs de normalisation, mais il n’est chiffré nulle part publiquement pour ce changement. Le coût documentaire, lui, est certain.
| Situation | Recommandation |
|---|---|
| Pipeline haché qui marche, taux de correspondance correct | ne rien changer, surveiller le taux après le 16 |
| Taux de correspondance faible à cause de la normalisation | corriger d’abord la normalisation avant de parler de clair |
| Connecteur CRM natif | demander à l’éditeur ce qui change et s’il garde l’option hachée |
| Données sensibles (santé, finance, mineurs) | rester sur le hachage, l’AIPD est trop exposée |
| Volonté de basculer | test sur une liste, comparaison des taux, mise à jour du registre, de l’AIPD et de la politique avant la généralisation |
Checklist avant le 16 novembre
- Inventorier chaque flux qui envoie des données clients à Google Ads : listes Customer Match, conversions hors ligne, connexions CRM, imports de fichiers, appels à la Data Manager API.
- Noter, flux par flux, le taux de correspondance actuel dans les diagnostics de Data Manager.
- Demander aux éditeurs de connecteurs CRM ce qui change et si l’envoi haché reste possible.
- Vérifier que chaque requête d’export ne retient que les clients ayant consenti au traitement publicitaire.
- Relire registre, AIPD et politique de confidentialité, et repérer les phrases qui supposent un envoi haché.
- Décider avec le DPO, flux par flux : hachage maintenu, hachage puis chiffrement, ou chiffrement seul.
- Après le 16, recontrôler les uploads planifiés (erreurs, volumes, taux de correspondance) pendant au moins deux semaines.
- Surveiller les pages d’aide de Data Manager, qui devraient finir par documenter l’échéance et le sort des uploads hachés.
Le hachage n’a jamais été une cape d’invisibilité, juste une façon de garder l’adresse lisible chez vous. Google vous propose désormais de la lui confier dans une salle blanche. C’est peut-être un bon deal pour vos taux de correspondance, à condition de le signer en connaissance de cause, et pas parce qu’un email l’a décidé à votre place.