Mise à jour « Google Enhanced Conversions » 2026 : la plupart des agences n'ont toujours pas vérifié si la leur fonctionne

En juin 2026, Google Ads a modifié le fonctionnement des « Conversions améliorées ». Les deux produits distincts, « Conversions améliorées pour le Web » et « Conversions améliorées pour les prospects », qui disposaient chacun de leur propre écran de paramètres et de leur propre méthode de mise en place, ont été fusionnés en un seul bouton d'activation/désactivation.

Google a présenté ça comme une simplification, et c'en est bien une. Mais cette mise à jour a aussi un effet moins évident : elle supprime le rappel visible indiquant que « Conversions améliorées » est un système actif avec des éléments qui évoluent, et non pas un simple bouton qu'on active une fois pour toutes avant de l'oublier. Si tu as configuré le tien il y a un moment et que tu n’y as pas jeté un œil depuis, il y a de fortes chances qu’il ne serve plus à rien.

Une grande partie des configurations de « Conversions améliorées » semblent actives dans Google Ads, alors qu’elles envoient peu ou pas de données exploitables. Le bouton est sur « activé ». L’action de conversion indique une activité. Mais les données utilisateur hachées, qui permettent à toute la fonctionnalité de fonctionner, n’arrivent jamais réellement chez Google sous une forme exploitable. Personne ne s’en rend compte, car rien dans l’interface n’indique clairement qu’il y a un problème.

Voici ce qui a réellement changé en juin 2026, pourquoi les configurations de « Conversions améliorées » de Google échouent sans afficher d'erreur visible, comment vérifier si c'est ton cas, et pourquoi le fait de faire passer la configuration par GTM server-side élimine d'emblée la plupart des sources d'échec.

À quoi servent vraiment les « conversions améliorées » de Google ?

Les conversions améliorées existent parce que le suivi des conversions basé sur les cookies présente une lacune. Normalement, Google Ads attribue une conversion à l'aide d'un GCLID, un identifiant de clic stocké dans un cookie du navigateur. Quand ce cookie manque (s'il est bloqué, effacé ou si l'utilisateur a effectué la conversion sur un autre appareil), la conversion a quand même lieu, mais Google ne peut pas la relier à l'annonce qui l'a générée.

Les conversions améliorées comblent en partie ce manque grâce à un deuxième identifiant. Lorsqu'un utilisateur effectue une conversion, ton site recueille des données de première partie (généralement une adresse e-mail) et les hache à l'aide de l'algorithme SHA-256 avant de les envoyer à Google. Google compare ce hachage à ceux dérivés de ses propres données de comptes connectés. S’ils correspondent, la conversion est attribuée même sans GCLID valide.

C'est tout le principe : hachage, envoi, comparaison. Le hachage est à sens unique, donc Google ne reçoit jamais d'adresse e-mail lisible, mais seulement une empreinte de celle-ci.

Pour obtenir toutes les informations détaillées, notamment sur les conversions améliorées pour le Web par rapport aux prospects, le fonctionnement du taux de correspondance et les instructions de configuration pour chaque méthode de mise en œuvre, consulte notre guide complet sur les conversions améliorées de Google.

Mise à jour de juin 2026 sur les conversions améliorées de Google : ce qui a changé

Avant juin 2026, les « Conversions améliorées pour le Web » et les « Conversions améliorées pour les prospects » étaient des fonctionnalités distinctes. Chacune disposait de son propre écran de paramètres, et les annonceurs devaient choisir une méthode de mise en œuvre (la balise Google, GTM ou l'API) par action de conversion.

À partir d'avril 2026, Google a commencé à accepter simultanément les données fournies par les utilisateurs via les balises de site web, Data Manager et les connexions API, au lieu d'imposer une seule méthode. À partir de juin 2026, cette flexibilité est devenue la norme : les deux produits ont fusionné en une seule fonctionnalité avec un bouton marche/arrêt unique, et l'écran de sélection de la méthode a complètement disparu de l'interface.

Pour les agences qui gèrent plusieurs comptes, il y a trois choses à vérifier après la fusion.

Les configurations existantes ont été migrées automatiquement, mais uniquement pour les comptes qui avaient déjà accepté les conditions d'utilisation de Google relatives aux données client. Si un compte client n'a jamais explicitement accepté ces conditions (ce qui arrive souvent quand la fonctionnalité « Conversions améliorées » a été activée par une ancienne agence ou une équipe interne qui n'a pas terminé la configuration), la migration ne se passe pas bien, et le compte peut afficher la fonctionnalité « Conversions améliorées » comme disponible mais inactive.

Le changement d'interface a fait disparaître certaines des pistes de diagnostic qui existaient auparavant. Quand la sélection des méthodes était visible, tu pouvais au moins vérifier quelle voie d'implémentation une action de conversion était censée utiliser. Maintenant que cet écran n'existe plus, la vérification de la configuration repose davantage sur les diagnostics et moins sur la correspondance entre la page des paramètres et ce à quoi tu t'attends.

La possibilité de se désinscrire existe toujours au niveau de l'action de conversion, et rien dans cette fusion ne modifie l'exigence sous-jacente liée aux Conditions de traitement des données. Google attend toujours des annonceurs qu'ils aient accepté ces conditions et qu'ils traitent les données fournies par les utilisateurs conformément à sa politique. Le bouton de désactivation est devenu plus simple, mais l'obligation de conformité reste inchangée.

Les configurations qui fonctionnent continuent de fonctionner. Mais c'est le moment idéal pour vérifier les comptes qui ont été créés il y a un certain temps et qui n'ont jamais été réexaminés, car la fusion est exactement le genre de changement qui fait ressortir des problèmes que personne n'avait repérés.

Pourquoi « Enhanced Conversions » échoue sans rien dire et comment le repérer

La fonctionnalité « Conversions améliorées » de Google présente un type d'échec particulier qui passe facilement inaperçu. La balise de conversion peut se déclencher correctement, la conversion est bien enregistrée et Google Ads peut afficher l'action de conversion comme active, alors que les données améliorées elles-mêmes n'arrivent jamais réellement chez Google sous une forme exploitable.

Le rapport de diagnostic de Google définit justement plusieurs statuts pour cette raison. « Enregistrement des conversions améliorées » signifie que ça marche vraiment. « En attente de données de conversion améliorées » peut simplement vouloir dire que c'est encore trop tôt, car le statut peut mettre jusqu'à 48 heures à s'actualiser. Mais « Problèmes de configuration détectés » et, pour les prospects, un statut « Urgent » indiquent tous deux une configuration qui a l'air active mais qui ne produit rien d'utile. C'est dans cet écart entre ces deux états que la plupart des configurations défaillantes restent bloquées pendant des mois, sans que personne ne pense à y jeter un œil.

Les causes les plus courantes ne sont pas spectaculaires. Ce sont de petits détails de configuration qui ne génèrent aucune erreur :

• Le champ « user_data » est présent mais vide. La balise se déclenche, le wrapper arrive chez Google, mais le champ de l'adresse e-mail ou du numéro de téléphone (sous forme de hachage) qu'il contient est vide. Google enregistre le ping comme reçu et passe à autre chose. Il ne signale pas qu'« il n'y avait rien d'utile là-dedans ». Il s'agit généralement d'une variable GTM qui n'a jamais été mappée à la bonne clé dataLayer, et c'est la cause la plus courante d'une configuration qui a l'air de bien fonctionner mais qui n'ajoute aucun signal.
• Double hachage. Certaines équipes hachent elles-mêmes l'adresse e-mail avant de l'envoyer vers le dataLayer, puis GTM ou la balise Google la hachent à nouveau avant l'envoi. Au final, Google compare un hachage d'un hachage à sa propre base de données de hachages uniques. Il n'y a jamais de correspondance, et aucune erreur ne permet d'identifier la cause. La solution, c'est d'envoyer systématiquement la valeur brute et de laisser GTM ou gtag.js se charger du hachage.
• Activer le bouton sans toucher l'étiquette. L'activation des conversions améliorées dans l'interface Google Ads ne reconfigure pas automatiquement ta balise GTM. Si les champs « user_data » de la balise de conversion n'ont jamais été configurés, activer le bouton au niveau du compte n'a aucun effet, si ce n'est de faire apparaître le paramètre comme actif.
• Problèmes avec les sélecteurs CSS après la refonte du site. Si la configuration initiale récupérait le champ « e-mail » en ciblant un sélecteur CSS sur la page de confirmation, une refonte qui modifierait les identifiants ou les noms de classe des éléments rendrait le sélecteur inopérant sans que personne ne s'en aperçoive. La balise se déclenche toujours, mais elle ne trouve plus rien à hacher. Les variables de la couche de données ne posent pas ce problème, ce qui explique en partie pourquoi elles constituent l'option la plus fiable.
• Un système de consentement qui ressemble à une variation normale. Quand le consentement « ad_user_data » est refusé, Enhanced Conversions n'envoie tout simplement pas les données hachées de cet utilisateur. C'est un comportement normal, pas un bug, mais ça veut dire que le taux de correspondance baisse naturellement dans les régions où le consentement est très répandu. Le plus dur, c'est de faire la différence entre une variation attendue liée au consentement et une véritable défaillance technique, ce qui est difficile à faire sans vérifier directement les chiffres.

Pour diagnostiquer ce genre de problème, commence par faire ces deux vérifications : ouvre le mode Aperçu de GTM et vérifie que l'objet `user_data` de la balise de conversion contient bien des valeurs hachées, et non un objet vide. Vérifie ensuite la requête réseau elle-même pour voir si le paramètre `em` est présent. S'il manque, ça veut dire que la balise n'est pas configurée pour l'envoyer. S’il est présent mais qu’il s’affiche sous la forme « tv.1~em. » sans rien après, ça veut dire que le champ est déclenché à vide. Dans tous les cas, la solution se trouve dans GTM, pas dans l’écran des paramètres de Google Ads.

Comment GTM server-side rend les conversions améliorées de Google plus fiables

La plupart des causes d'échec mentionnées ci-dessus ont un point commun : elles se produisent dans le navigateur, où la balise dépend du DOM de la page, du bon remplissage de la couche dataLayer et du fait que rien n'intercepte la requête avant qu'elle ne soit envoyée. Transférer la configuration vers GTM server-side n'élimine pas tous les risques d'échec, mais ça en supprime plusieurs en changeant l'endroit où le traitement s'effectue.

Avec un conteneur serveur en place, le rôle du navigateur se réduit. Il envoie l'événement (avec les données brutes de l'utilisateur) à ton propre point de terminaison propriétaire. C'est le conteneur serveur, et non une balise côté navigateur, qui construit l'objet user_data, applique le hachage et transmet la requête à Google. Ce simple changement élimine complètement le problème du double hachage, car la logique de hachage se trouve désormais à un seul endroit, au lieu d'être répartie entre la page et la balise.

Ça élimine aussi le risque lié aux bloqueurs de pub. Une balise « Enhanced Conversions » côté navigateur envoie sa requête depuis le navigateur de l'utilisateur, ce qui veut dire qu'un bloqueur de pub ou une fonctionnalité de protection contre le suivi peut l'intercepter ou la supprimer avant même que Google ne la voie. La balise peut être parfaitement configurée et tu peux quand même perdre des données à cause d'un facteur qui échappe totalement à ton contrôle. Une requête de serveur à serveur, envoyée depuis ton conteneur vers l'API de Google, ne présente pas ce risque, car il n'y a rien dans le navigateur qu'un bloqueur puisse intercepter.

À noter: l'étape server-side n'est utile que si le trajet entre le navigateur et le serveur est lui-même résilient. Assure-toi d'utiliser le script de suivi amélioré de TAGGRS pour que cette requête initiale reste totalement invisible pour les bloqueurs de pub, sinon le risque d'interception se déplace simplement d'une étape plus tôt dans la chaîne.

Rien de tout ça ne remplace la nécessité de bien configurer les choses. Une configuration server-side avec un champ `user_data` vide reste un champ `user_data` vide. Mais ça veut dire qu’il y a moins d’endroits où une configuration qui marche peut cesser de fonctionner sans générer d’erreur, ce qui est exactement le genre de panne difficile à repérer si on ne la cherche pas activement. Pour les agences qui gèrent plusieurs comptes clients, cette différence de fiabilité s’accumule rapidement : moins de défaillances silencieuses, ça veut dire moins d’audits, moins de lacunes dans les données d’attribution, et moins de discussions pour expliquer aux clients pourquoi leurs chiffres de conversion ne correspondent pas à la réalité.

• Pour connaître la procédure complète de configuration, y compris la configuration au niveau des champs pour Google Ads via GTM server-side, consulte la documentation sur la configuration des conversions améliorées et la présentation du suivi server-side de Google Ads.
• Si tu gères également des conversions hors ligne à partir d'un CRM en plus des « Conversions améliorées pour les prospects », la documentation sur la balise de conversion hors ligne explique cette configuration spécifique, et cet article sur la manière de démontrer le ROAS réel des conversions hors ligne explique pourquoi ces données sont importantes pour le reporting, au-delà du simple Smart Bidding.

Conversions améliorées de Google et RGPD : ce que les organismes de l'UE doivent savoir

Enhanced Conversions transmet des données à caractère personnel, et le hachage ne change rien à cette classification au regard du RGPD. Un hachage SHA-256 d’une adresse e-mail correspond à des données pseudonymisées, et non à des données anonymisées, car Google (le destinataire) peut le comparer aux données qu’il détient déjà et réidentifier la personne qui se cache derrière. Cette distinction est importante : les données pseudonymisées restent pleinement soumises au RGPD, avec toutes les mêmes obligations en matière de base légale, de consentement et de droits des personnes concernées.

Concrètement, ça veut dire que Google Enhanced Conversions a besoin que le signal de consentement « ad_user_data » du Consent Mode V2 soit accordé avant de se déclencher. Si un utilisateur refuse ce consentement, la balise Google n'inclura pas du tout les données hachées dans l'événement de conversion. C'est voulu, ce n'est pas un bug, et c'est le comportement correct et conforme. La modélisation agrégée des conversions s'applique toujours aux utilisateurs qui n'ont pas donné leur consentement.

Pour les agences de l'UE, le risque concret ne vient généralement pas de la fonctionnalité « Conversions améliorées » en soi. C'est plutôt lié aux configurations où l'autorisation « ad_storage » est accordée, mais où « ad_user_data » n'a jamais été explicitement configurée : du coup, la bannière de consentement fonctionne techniquement, mais le signal sous-jacent que Google vérifie pour les « Conversions améliorées » n'a jamais été mis en place. La balise se déclenche, les données sont envoyées, mais il n’y a aucun enregistrement de consentement pour les justifier. C’est une lacune de conformité qui n’apparaîtra pas dans un rapport de taux de correspondance, car du point de vue de Google, tout semble fonctionner normalement. C’est le genre de problème qu’on ne découvre qu’en cherchant bien, et le genre de chose qui coûte cher à expliquer après coup.

Le GTM server-side ne supprime pas l'obligation de consentement, et c'est très bien comme ça. Ce qu’il fait, c’est centraliser l’endroit où le consentement est vérifié. Au lieu de compter sur plusieurs balises server-side pour que chacune respecte correctement l’état du consentement, le conteneur serveur peut contrôler l’ensemble des données utilisateur en un seul endroit avant que quoi que ce soit ne soit envoyé à Google, Meta ou n’importe quelle autre plateforme.

Pour en savoir plus sur les signaux de consentement et le suivi server-side, consulte le guide sur le RGPD et le suivi server-side.

La place de TAGGRS

Vérifier les conversions améliorées sur tous les comptes clients après une mise à jour de Google, c'est pas vraiment faisable pour la plupart des agences. Personne n'a le temps d'activer le mode Aperçu de GTM sur cinquante comptes à chaque fois que Google change quelque chose.

TAGGRS gère les conversions améliorées via le même conteneur GTM server-side qui s'occupe du reste du suivi d'un compte. Comme le hachage et la construction des données utilisateur se font server-side plutôt que via un ensemble disparate de balises de navigateur, il y a moins d'endroits où une erreur silencieuse, comme une charge utile vide ou un champ doublement haché, peut se glisser sans que personne ne s'en aperçoive.

La gestion des consentements est aussi centralisée. Au lieu de vérifier si chaque balise server-side sur le site d'un client respecte correctement la variable `ad_user_data`, le conteneur serveur s'en charge de manière centralisée, avant que les données utilisateur ne soient transmises à Google, Meta ou une autre plateforme.

Pour les équipes qui utilisent déjà le suivi Google Ads via TAGGRS, les « conversions améliorées » font partie du même processus que tous les autres événements de conversion, et peuvent être suivies depuis les tableaux de bord analytiques centralisés du compte TAGGRS.

Conclusion

La mise à jour de juin 2026 a rendu les « Conversions améliorées » plus faciles à activer… et plus faciles à oublier. C'est le risque qui se cache derrière une simplification : moins de paramètres à gérer, ça veut aussi dire moins de rappels visibles pour vérifier si ce que tu as configuré il y a des mois fonctionne toujours comme il faut.

Une configuration qui semble active dans Google Ads peut quand même ne rien envoyer d'utile. La seule façon de le savoir, c'est de vérifier le rapport de diagnostic et la requête réseau réelle, pas juste le bouton. Et si le but est de réduire le nombre d'endroits où cette erreur peut se produire, déplacer la configuration server-side élimine la plupart des points dépendants du navigateur où elle a tendance à se produire.

L'audit des conversions améliorées sur tous les comptes clients, c'est exactement le genre de tâche qu'une configuration server-side est censée t'éviter. Tu peux créer un compte TAGGRS gratuit pour te lancer, ou consulter les guides de configuration si tu préfères d'abord voir comment ça marche.

FAQ

Qu'est-ce qui a changé avec la mise à jour « Enhanced Conversions » de juin 2026 ?

Google a fusionné les options « Conversions améliorées pour le Web » et « Conversions améliorées pour les prospects » en un seul bouton d'activation/désactivation et a supprimé l'écran où les annonceurs choisissaient une méthode de mise en œuvre. Les comptes existants qui avaient déjà accepté les conditions d'utilisation de Google relatives aux données clients ont été migrés automatiquement. Le mécanisme sous-jacent de hachage et de mise en correspondance n'a pas changé.

Pourquoi les « Conversions améliorées » semblent-elles actives alors qu'elles ne fonctionnent pas vraiment ?

Parce que la balise de conversion et les données enrichies sont deux choses distinctes. La balise peut se déclencher et la conversion peut être enregistrée normalement même si le champ « user_data » qu'elle contient est vide, comporte un double hachage ou est tout simplement absent. Google Ads affiche quand même l'action de conversion comme active dans les deux cas, puisque la conversion de base est toujours suivie correctement.

Comment je peux vérifier si ma configuration des « Conversions améliorées » envoie bien des données exploitables ?

Ouvre le mode « Aperçu » de GTM, lance une conversion test et vérifie que l'objet « user_data » contient bien des valeurs hachées et n'est pas vide. Vérifie ensuite la requête réseau pour voir si le paramètre « em » est présent. S'il manque ou s'il est vide, les données enrichies n'arrivent pas à Google, même si la conversion de base est suivie.

Est-ce que le GTM server-side résout tous les problèmes liés aux conversions améliorées ?

Non. Un champ mal configuré reste mal configuré, peu importe où le hachage a lieu. Ce que le GTM server-side élimine, ce sont les points de défaillance liés au navigateur : les bloqueurs de pub qui interceptent la requête, les sélecteurs CSS qui ne fonctionnent plus après une refonte du site, et le double hachage causé par une logique répartie entre la page et la balise.

Les conversions améliorées sont-elles toujours conformes au RGPD après la mise à jour ?

Oui, et cette exigence n'a pas changé. La fonctionnalité « Conversions améliorées » a toujours besoin du consentement « ad_user_data » accordé via le Consent Mode V2 avant de pouvoir envoyer des données hachées. Le hachage ne rend pas les données anonymes au regard du RGPD, puisque Google peut toujours les recouper avec les données de compte qu'il détient.

Est-ce que je dois refaire ma configuration des « Conversions améliorées » à cause de la fusion ?

Pas forcément. Si ton compte avait déjà accepté les conditions relatives aux données clients, la migration s'est faite automatiquement. Ça vaut quand même le coup de jeter un œil au rapport de diagnostic, car la fusion est un bon moyen de repérer une configuration qui était déjà défaillante avant la mise à jour, sans que personne ne s'en soit rendu compte.