Enhanced Conversions (conversions améliorées) Google Ads sur une landing page : le hachage SHA-256 expliqué

Un visiteur remplit votre formulaire, atterrit sur la page de remerciement, votre tag de conversion Google Ads se déclenche — et pourtant, dans le compte, la conversion n'apparaît jamais, ou apparaît des jours plus tard sous forme « modélisée ». Ce n'est pas un bug isolé : c'est la conséquence directe de tout ce qui bloque le suivi par cookie avant même que Google puisse le compter — bloqueurs de publicité, Safari qui limite la durée de vie des cookies tiers, et le Consent Mode v2 lui-même, qui refuse ad_storage tant que le visiteur n'a pas répondu au bandeau. La réponse que Google pousse depuis plusieurs années, et qu'il a encore simplifiée en 2026, s'appelle les conversions améliorées (« Enhanced Conversions ») : au lieu de dépendre uniquement d'un cookie, la landing page envoie une empreinte hachée de l'email ou du téléphone saisi dans le formulaire, que Google peut recouper avec les comptes connectés. Voici ce que ça change concrètement, et comment l'installer sans se tromper.

Ce que Google appelle une « conversion améliorée »

Le principe est distinct du Consent Mode, avec lequel on le confond souvent. Le Consent Mode gère le droit d'envoyer un signal ; les conversions améliorées améliorent la qualité du signal une fois ce droit accordé. Concrètement, en plus du tag de conversion classique (déclenché sur la page de remerciement, jamais au clic sur le bouton — même logique que pour l'événement Lead côté pixel Meta), la landing page transmet à Google Ads une ou plusieurs données saisies dans le formulaire : email, téléphone, ou adresse postale. Ces données ne partent jamais en clair : elles sont hachées avec l'algorithme SHA-256, une fonction à sens unique — impossible de retrouver l'email d'origine à partir du hash. Google compare ensuite ce hash à ceux qu'il détient déjà pour ses propres comptes utilisateurs connectés, et quand ça correspond, il relie la conversion au clic publicitaire d'origine, même sans cookie exploitable.

For web ou for leads : la distinction qui détermine qui hache quoi

C'est le point le plus mal compris, et la source la plus fréquente d'implémentations bancales. Google Ads distingue deux mécanismes qui portent presque le même nom :

• Enhanced conversions for web — pensé pour un tag de conversion classique posé sur la page de remerciement. Le formulaire transmet les données en clair au tag Google (via gtag ou une balise GTM), et c'est le script de Google, exécuté dans le navigateur du visiteur, qui se charge lui-même du hachage SHA-256 avant l'envoi. Il ne faut donc jamais hacher soi-même les données envoyées par cette voie : un double hachage casse la correspondance, silencieusement.
• Enhanced conversions for leads — pensé pour les conversions hors ligne : un formulaire de contact qui débouche sur un devis signé une semaine plus tard, un appel commercial converti en client trois jours après. Ici, c'est vous (ou votre CRM) qui devez hacher les données en SHA-256 avant de les envoyer à Google, via l'import de conversions hors ligne ou l'API Google Ads.

Pour la grande majorité des landing pages de génération de leads — un template comme immobilier, coach-consultant ou saas-waitlist — c'est for web qui s'applique dès que la conversion Google Ads se déclenche directement sur la page de remerciement. For leads ne devient pertinent que si le lead se transforme en client plus tard, hors ligne, et que ce second événement doit lui aussi remonter dans Google Ads pour optimiser les enchères sur la vraie valeur, pas seulement sur le formulaire rempli.

L'implémenter sur une landing page Next.js

Sur une page de remerciement dédiée, l'installation en for web via gtag tient en un appel, posé juste avant le déclenchement du tag de conversion habituel — décrit dans notre guide de tracking GA4 pour l'équivalent Analytics :

1. Collecter la donnée au bon format — au moment de la soumission du formulaire, récupérer l'email (et le téléphone si demandé) tels que saisis, sans les modifier.
2. Les transmettre en clair à Google — un appel gtag('set', 'user_data', { email: '...', phone_number: '...' }) juste avant l'appel gtag('event', 'conversion', {...}) classique ; c'est ce même appel gtag qui pilote déjà le Consent Mode, donc il doit respecter le même ordre : jamais avant que le visiteur ait consenti au tracking publicitaire.
3. Ou passer par Google Tag Manager — dans un conteneur GTM, activer « Enhanced Conversions » sur la balise de conversion Google Ads et pointer vers les champs du formulaire (email, téléphone) via une variable de couche de données ; GTM gère alors le hachage automatiquement, sans ligne de code côté page, ce qui rejoint l'approche décrite dans notre guide GTM sur une landing page.

Le déploiement sur Vercel ne change rien à cette mécanique (voir notre guide de déploiement Next.js), mais vérifiez un point souvent oublié : si votre formulaire redirige le visiteur ailleurs qu'une page de remerciement dédiée avant que le tag ne se déclenche, l'appel user_data n'a tout simplement pas le temps de partir.

Ce qui a changé en 2026 : un seul réglage

Jusqu'ici, activer les conversions améliorées obligeait à choisir entre plusieurs méthodes d'implémentation qui ne se recoupaient pas complètement — balise Google, Google Tag Manager, import de données via l'API. Courant 2026, Google a engagé l'unification de ces réglages : les comptes migrent vers un interrupteur unique côté conversion, qui accepte les données saisies quelle que soit la voie technique choisie (balise du site, Data Manager, ou connexion API), et la distinction historique entre le réglage « for web » et le réglage « for leads » a elle aussi été fusionnée dans une seule bascule. Le mécanisme technique décrit plus haut — hachage automatique côté navigateur pour un tag classique, hachage manuel pour un import hors ligne — reste inchangé ; c'est la configuration dans l'interface qui se simplifie. Si votre compte affiche encore les anciens réglages séparés, rien d'urgent à faire : la migration se fait automatiquement, sans casser un tag déjà posé correctement.

RGPD : la même règle que pour tout signal publicitaire

Le hachage SHA-256 ne dispense de rien côté RGPD : un email haché reste une donnée personnelle tant qu'il permet, par recoupement, d'identifier une personne — ce qui est exactement son usage ici. L'appel user_data obéit donc à la même règle que le reste du tracking publicitaire décrit dans notre article sur le Consent Mode v2 : il ne doit jamais partir avant un consentement explicite au ad_storage et à ad_user_data, recueilli via un bandeau de cookies conforme. Notre guide RGPD pour formulaire détaille ce que le formulaire lui-même doit par ailleurs respecter, indépendamment du tracking qui en découle.

Ce que dit la recherche sur ces mécanismes « privacy-preserving »

Les conversions améliorées appartiennent à une famille plus large d'outils que Google, Meta et Apple présentent chacun comme des solutions de mesure « respectueuses de la vie privée ». Une étude de McGuigan, Sivan-Sevilla, Parham et Shvartzshnaider, publiée dans la revue New Media & Society, a analysé en détail les documents techniques de ces trois entreprises pour comprendre ce que « privacy-preserving » signifie réellement dans leurs implémentations : les auteurs montrent que ces solutions définissent la vie privée avant tout comme de l'anonymat statistique et une limitation de l'accès aux données brutes — le hachage en est un exemple typique — plutôt que comme un contrôle réel donné à l'utilisateur sur l'usage qui en est fait, et proposent une lecture critique de ces mécanismes à travers la théorie de l'intégrité contextuelle (étude sur Google Scholar). Une nuance utile au moment d'installer ces outils sans réfléchir : le hachage protège la donnée en transit, il ne change rien au fait que l'email d'un visiteur devienne, une fois recoupé côté Google, un identifiant publicitaire à part entière — d'où l'obligation de consentement qui reste entière.

Erreurs fréquentes

• Hacher soi-même les données envoyées via gtag for web — le script de Google s'en charge déjà ; un double hachage produit un hash que rien ne peut plus recouper.
• Confondre for web et for leads — utiliser l'import hors ligne (données pré-hachées) pour une conversion qui se déclenche déjà sur la page de remerciement, ou l'inverse.
• Envoyer user_data avant le consentement — même erreur que pour le Consent Mode v2, avec les mêmes conséquences juridiques.
• Transmettre des champs mal normalisés — un email avec des espaces ou une casse incohérente réduit le taux de correspondance sans qu'aucun message d'erreur ne le signale.
• Oublier de vérifier après une refonte — un champ de formulaire renommé ou une page de remerciement déplacée casse silencieusement l'appel user_data, comme le reste du tracking décrit dans notre article sur le pixel Meta.

Sur une landing page à budget publicitaire réel, quelques points de correspondance en plus se traduisent directement par un coût par lead qui redescend, parce que l'algorithme d'enchères de Google Ads dispose enfin d'un signal complet pour apprendre. Les 10 templates LanderKit livrent une page de remerciement dédiée dès l'installation — l'endroit exact où poser cet appel user_data — sur une base Next.js assez sobre pour que le câblage prenne quelques lignes, pas un chantier : 89 € le template, 229 € le pack complet.