Data Manager ou GTM server-side : où doit vivre la logique de vos flux CRM ?

Le vrai sujet n’est pas de désigner un gagnant. Il s’agit de décider où vous voulez loger vos règles : dans l’outil de Google ou dans votre infrastructure.

Ce que fait réellement Data Manager

Google le présente comme un outil d’import en point-and-click : vous connectez une source une fois, puis vous l’activez vers plusieurs destinations Google. Derrière l’interface, il y a une API. Ses release notes datent la v1.0 du 2 avril 2025 (audiences vers Google Ads et Display & Video 360). La v1.2, du 6 août 2025, a ajouté les conversions hors ligne et les conversions optimisées pour prospects. Google la recommande aussi comme successeur du Measurement Protocol pour l’envoi d’événements vers GA4. La documentation bouge de version en version, donc relisez les release notes avant de figer une architecture.

Trois profils, trois réponses

Petite équipe, un CRM, des destinations 100 % Google. L’interface suffit. Analytics Mania résume bien le cas : sans personne pour écrire ou lire un peu de code, ni serveur en place, c’est l’interface qui vous attend. Vous n’avez aucun conteneur à héberger.

Équipe déjà équipée en sGTM, plusieurs régies, besoin d’enrichir. Ici, le server-side reste pertinent. Il vous permet de nettoyer, modifier et enrichir les événements avant de les renvoyer où vous voulez, alors que Data Manager n’envoie qu’à Google. Simo Ahava montre l’intérêt avec un exemple simple : collecter côté navigateur un achat avec son transaction_id, puis récupérer le reste des données depuis votre moteur de ventes. Marge, LTV et statut client se traitent de la même façon.

Volume élevé, développeurs disponibles, Google seul. Google présente l’API comme la solution des organisations qui veulent passer à l’échelle par l’automatisation, ou via un partenaire data qui s’y intègre pour vous. Appelez-la depuis votre backend, sans passer par sGTM.

Unnest recommande d’utiliser GTM Server Side pour alimenter la Data Manager API. Unnest vend du sGTM, lisez donc cette recommandation comme celle d’un fournisseur. Je n’ai trouvé aucune documentation Google décrivant ce branchement : c’est une architecture de consultants, pas une fonctionnalité documentée. Sur le budget, Google ne publie rien de comparable. Chiffrez vous-même l’hébergement et la maintenance du serveur.

Le consentement : deux couches que l’on confond

La première est technique. L’API prévoit un objet de consentement avec deux champs, adUserData et adPersonalization, chacun valant non spécifié, accordé ou refusé. Le consentement porté par l’utilisateur prime sur celui de la requête. Pour Customer Match dans l’EEE, Google exige depuis mars 2024 que les deux champs soient à GRANTED. Un statut non spécifié compte pour un consentement non accordé.

La seconde est juridique, et aucun drapeau ne la remplace. Le 30 décembre 2025, la CNIL a sanctionné de 3,5 millions d’euros une société qui transmettait les données de son programme de fidélité à un réseau social. L’entreprise invoquait le consentement recueilli à l’adhésion, pour des SMS et des e-mails. Pour la CNIL, accepter des offres commerciales ne vaut pas accord pour combiner ces données avec celles d’un réseau social.

À ma lecture, rien dans la documentation Google n’indique qu’elle contrôle la validité juridique du statut que vous envoyez. L’API transporte un statut, elle ne l’audite pas.

Reste l’outillage. Stape affirme que l’interface Data Manager ne permet pas d’appliquer de logique de consentement avant l’envoi. Stape vend aussi du sGTM, et je n’ai pas vérifié ce point dans la documentation Google. Si c’est exact, le filtrage doit se faire dans l’export CRM. Avec sGTM, il faut une porte de consentement avant la diffusion vers chaque régie, puisque les champs de Google ne concernent que Google.

Un flux qui tient la route

CRM (consentement "ciblage publicitaire", date, version du libellé)
  -> export filtré : seuls les "oui" sortent
  -> sGTM ou script backend : mapping vers adUserData / adPersonalization
  -> Data Manager API -> Google Ads / GA4
  -> branche parallèle, consentement propre au partenaire -> Meta, autres régies

L’IA vous fait gagner du temps sur le mapping des champs et sur la génération de cas de test, avec un contact sans consentement, un statut vide ou un libellé périmé. Elle ne tranche pas la base légale. Cela reste le travail de votre DPO.

Ouvrez aujourd’hui votre dernier export CRM et comptez les lignes dont le champ de consentement publicitaire est vide. Google les traitera comme non consenties, et la CNIL aussi.