J’ai l’impression que Stape reste assez mal connu en France. Ou plutôt, connu pour une seule chose : héberger du Google Tag Manager server-side pour pas très cher. Ce qui est une qualité, sauf dans notre secteur, où un prix accessible déclenche parfois davantage de méfiance qu’un devis à cinq chiffres accompagné d’un PDF intitulé « Enterprise Data Acceleration ».
À force de résumer Stape à son tarif, on passe à côté de ce qui me plaît vraiment dans l’outil : une série de fonctionnalités bien pensées, qui répondent à des problèmes très concrets d’implémentation et d’exploitation. Des problèmes que vous finissez sinon par résoudre avec du code maison, trois onglets de documentation et une légère dégradation de votre rapport à l’humanité.
Cet article est réalisé en partenariat avec Stape. Je préfère le dire maintenant, plutôt qu’en police 8 entre les mentions légales et le bouton de gestion des cookies. J’utilise Stape au quotidien et j’aurais aussi eu envie d’écrire cet article sans ce partenariat. Par souci d’équité, je ne ferai aucun comparatif avec Addingwell, qui est également un outil que j’apprécie.
L’idée est donc de vous expliquer ce que je trouve réussi, ce que je considère comme prioritaire, et les fonctionnalités sur lesquelles je n’ai pas encore suffisamment de recul. Je parlerai ici de l’hébergement sGTM et des outils qui l’accompagnent. Stape propose aussi des Gateways, mais je n’ai jamais eu à les utiliser : je vous épargne donc mon expertise très approfondie de leur page d’accueil.
D’abord, qu’est-ce qu’on achète chez Stape ?
Pour ceux qui arrivent, sGTM désigne la version server-side de Google Tag Manager. Au lieu de laisser le navigateur envoyer directement toutes les données aux différentes plateformes, on fait transiter les événements par un conteneur serveur, dans lequel on peut les traiter puis décider de ce qu’on transmet à chaque destination.
Stape fournit l’hébergement de ce conteneur et des outils autour. Cela vous évite de gérer vous-même toute l’infrastructure, mais le plan de marquage, les clients sGTM qui interprètent les requêtes, les tags, les déclencheurs et la qualité des données restent des sujets à traiter.
C’est une distinction assez importante. Un événement purchase envoyé trois fois ne devient pas une vente unique parce qu’il a traversé un serveur. Il devient trois événements hébergés dans de bonnes conditions.
Stape Global ou Stape Europe ?
Les deux offres ne se distinguent pas simplement par la ville dans laquelle vous posez votre serveur. Stape indique que l’offre Global s’appuie sur Google Cloud, tandis que Stape Europe repose sur Scaleway, avec une infrastructure européenne et une entité enregistrée en Estonie.
Pour un projet avec des exigences fortes sur les prestataires et la localisation du traitement, c’est donc un choix à faire dès le départ. Choisir une région européenne dans une offre mondiale et choisir Stape Europe ne répondent pas exactement à la même question.
En revanche, héberger votre conteneur en Europe ne suffit pas à garantir la conformité de toute la chaîne. Il faut aussi examiner les données collectées, les destinataires, les contrats et les traitements effectués. Stape le rappelle d’ailleurs sur sa page consacrée à l’hébergement européen. Le serveur intermédiaire vous donne des moyens de contrôle ; encore faut-il les utiliser.
Le prix : regardez les requêtes, puis les fonctionnalités
Au moment de la rédaction, les principaux paliers affichés en dollars, avec une facturation mensuelle, sont les suivants :
| Plan | Prix mensuel | Requêtes mensuelles incluses |
|---|---|---|
| Free | 0 $ | 10 000 |
| Pro | 20 $ | 500 000 |
| Business | 100 $ | 5 millions |
| Enterprise | 200 $ | 20 millions |
Il existe aussi des paliers intermédiaires, des offres sur mesure et une facturation annuelle à tarif réduit. La grille tarifaire de Stape reste la référence à consulter au moment de choisir.
Le piège, c’est de dimensionner l’abonnement à partir du seul nombre d’événements GA4. Un événement analytics et une requête facturée ne sont pas des unités interchangeables. Le chargement des scripts, les webhooks et les fonctionnalités activées peuvent aussi peser dans le volume. Stape propose justement un calculateur qui prend en compte plusieurs de ces paramètres.
Deuxième point : certaines fonctionnalités dépendent du plan. Vous pouvez donc avoir un trafic relativement modeste et un besoin qui vous oriente vers Business, par exemple pour les cookies personnalisés de Cookie Keeper ou le monitoring.
Mon conseil est de partir du volume réel et des fonctions nécessaires, puis de regarder le prix. Faire l’inverse, c’est prendre le forfait le moins cher pour découvrir ensuite que la fonctionnalité qui justifiait le projet habite à l’étage du dessus. Un grand classique du SaaS, juste après le bouton « Contact sales ».
Les power-ups : une bonne idée, à condition de ne pas tout cocher
Les power-ups sont des fonctionnalités que vous activez autour du conteneur. Ce que j’aime dans cette approche, c’est qu’elle rend accessibles des briques techniques assez différentes sans vous obliger à reconstruire chacune d’elles.
Leur valeur ne se mesure pas au nombre de boutons passés au vert. Elle se mesure au problème résolu et au temps que vous n’aurez pas à consacrer à maintenir une solution maison.
Je vais reprendre les catégories de l’interface utilisées pour ce tour d’horizon : Web GTM load, CDN, Utilities et Data enrich. C’est plus pratique que d’inventer ma propre taxonomie du tracking augmenté, même si je suis certain qu’on pourrait vendre une formation avec ce titre.
Pour vous donner tout de suite mon ordre de priorité : Custom Loader arrive en tête pour une collecte web, suivi de Cookie Keeper lorsque la continuité des identifiants est un enjeu, puis de Bot Detection et Ad Blocker Info pour mieux comprendre ce qu’on mesure. Les outils de debug et de monitoring sont à prévoir dès la mise en production. Le reste dépend beaucoup plus du contexte.
Web GTM load : commencer par faire arriver les données
Custom Loader : mon premier réflexe
Le Custom Loader sert à charger les scripts GTM et GA4 via votre domaine de collecte, avec des chemins modifiés. Il propose aussi une option de protection renforcée contre les adblockers, qui modifie la forme des requêtes pour les rendre moins reconnaissables par les règles de filtrage.
Pour une implémentation web, c’est mon indispensable. Vous pouvez construire le plus magnifique conteneur serveur du département : si le script censé envoyer les événements ne se charge pas, votre architecture sert surtout à héberger du silence.
Petite précision technique : du Base64 est un encodage, pas un hachage ni, à lui seul, un chiffrement. Ce qui compte ici est le mécanisme de chargement et de transformation des requêtes, pas le fait qu’une URL ressemble à un mot de passe Wi-Fi.
Et surtout, cela ne contourne pas tous les adblockers. Les listes et les méthodes de détection évoluent. Je considère cette fonctionnalité comme un moyen de rendre la collecte plus robuste, pas comme une promesse de récupérer 100 % des événements.
À la recette, vérifiez le chargement du script, l’arrivée de l’événement dans sGTM et l’absence de double chargement avec l’ancien snippet GTM. Testez aussi plusieurs navigateurs et configurations de blocage : un succès dans votre Chrome habituel ne constitue pas un protocole expérimental complet.
Cookie Keeper : très haut dans ma liste
Cookie Keeper vise à préserver la continuité de certains cookies first-party face aux restrictions de durée de vie des navigateurs, notamment Safari. On peut sélectionner les cookies concernés et, selon le plan, configurer des cookies personnalisés.
C’est cette granularité que je trouve particulièrement réussie. On raisonne cookie par cookie, en fonction des outils utilisés et des besoins de mesure, au lieu d’appliquer une réponse uniforme à toute la collecte.
Pour les équipes média, la continuité des identifiants peut faire une vraie différence dans la lecture des parcours et de l’attribution. Cela ne rend pas l’attribution parfaite, mais cela évite une partie des ruptures techniques qui compliquent son interprétation. Vos agences média vous remercieront peut-être. À défaut, elles auront un sujet de moins pour le point du mardi.
Cette restauration doit rester cohérente avec le consentement et les durées de conservation retenues. Vérifiez notamment les scénarios de refus et de retrait : un cookie soumis au consentement ne doit pas être rétabli contre le choix de l’utilisateur. Les règles rappelées par la CNIL continuent de s’appliquer.
Multi Domains : plusieurs domaines, un même conteneur
Multi Domains permet de rattacher plusieurs domaines personnalisés à un conteneur. Si votre groupe exploite marque-a.fr et marque-b.com et souhaite mutualiser son infrastructure sGTM, le besoin apparaît assez vite. Les limites de domaines dépendent du plan choisi.
C’est une fonctionnalité peu spectaculaire, mais utile dès que l’architecture dépasse un seul site. Attention toutefois : mutualiser le conteneur ne configure pas automatiquement le suivi cross-domain et ne fusionne pas les identités entre les marques. Vous partagez une infrastructure ; la logique de mesure reste à construire.
Anonymizer : décider aussi de ce qu’on ne transmet pas
Anonymizer permet de modifier, masquer ou supprimer certains champs destinés à GA4 : informations liées à l’IP, identifiants, paramètres d’URL ou caractéristiques techniques, selon les réglages.
Son intérêt est de traduire des exigences de minimisation en configuration concrète. C’est une bonne base de travail avec votre DPO : quels champs sont nécessaires, lesquels doit-on retirer, et quelles conséquences cela a-t-il sur les analyses ?
Il faut être explicite sur les compromis. Retirer des identifiants affecte les analyses utilisateur ; retirer des paramètres de campagne affecte l’attribution. Le nom du power-up ne garantit pas non plus que le résultat constitue une anonymisation au sens juridique. La CNIL distingue bien anonymisation et pseudonymisation.
Je ne le classe donc pas parmi les fonctions censées améliorer vos performances média. Je le classe parmi celles qui permettent de maîtriser ce qui sort du conteneur. Et ce contrôle a une valeur opérationnelle, même s’il ne produit pas une flèche verte dans le reporting.
CDN : File Proxy, le petit outil qui rend service
File Proxy permet de servir un fichier externe depuis un chemin de votre domaine sGTM et de définir sa durée de cache.
C’est pratique pour limiter la dépendance à certains domaines tiers, réduire certains blocages et maîtriser la distribution d’une ressource. Le cache peut aussi éviter de solliciter inutilement sa source.
Je parle bien de distribution : faire passer un script par un proxy ne réduit pas magiquement son poids ou son coût d’exécution. Un JavaScript trop lourd restera un JavaScript trop lourd, même après avoir obtenu une adresse locale et un justificatif de domicile.
Je l’utilise donc comme une réponse à un besoin identifié, avec une vérification du cache et des mises à jour. Le fichier doit continuer à évoluer quand son éditeur le modifie.
Utilities : les fonctions dont on découvre la valeur pendant un debug
sGTM Preview header config : une niche dans laquelle j’ai déjà vécu
Le power-up de configuration du header de preview permet de faire apparaître dans le debugger sGTM des requêtes qui ne viennent pas de la session de preview de votre site : application mobile, backend, webhook, etc.
On renseigne le jeton de preview, avec la possibilité de cibler un chemin ou une IP. C’est particulièrement utile lorsqu’on ne peut pas facilement ajouter soi-même le header X-Gtm-Server-Preview à la requête source.
Cela m’a déjà sauvé lors de debugs d’applications. Quand vous savez qu’un événement part quelque part, que tout le monde vous assure que « de notre côté c’est bon », et que vous avez enfin la possibilité de le regarder arriver, le niveau de sérénité remonte immédiatement.
Block Request by IP : utile, au bon endroit
Block Request by IP permet d’exclure des adresses du traitement par le conteneur. Pour une source indésirable identifiée ou du trafic de test, cela peut rendre service.
Je garde néanmoins la même préférence d’architecture : lorsqu’il s’agit de trafic malveillant, mieux vaut le bloquer le plus en amont possible, par exemple au niveau du pare-feu ou du CDN qui protège le point d’entrée. Un filtre dans l’environnement de tracking ne remplace pas la protection de l’infrastructure.
Google Service Account : pour construire son propre monitoring
Le power-up Google Service Account permet au conteneur de s’authentifier auprès de services Google Cloud, comme BigQuery ou Firestore, avec un compte de service.
J’aime beaucoup cette brique pour monter un monitoring personnalisé. Prenons un exemple : vous voulez vérifier que les événements d’achat reçus comportent bien une devise, un montant exploitable et un identifiant de transaction. Vous pouvez prévoir une validation côté serveur, puis enregistrer les anomalies dans BigQuery pour les suivre dans le temps.
Le power-up fournit l’accès authentifié. Les contrôles, l’écriture des résultats et les alertes restent à implémenter. Il ne surveille pas non plus tout le data layer du navigateur : seulement ce que vous faites parvenir au serveur.
Mais cela donne une base très intéressante pour dépasser le stade « j’ai testé un achat jeudi, tout allait bien ». Une méthode de recette respectable, jusqu’au vendredi.
XML to JSON et Dedicated IP : des besoins précis
Je n’ai pas encore utilisé XML to JSON. Son rôle est de convertir les données XML reçues sur le point d’entrée prévu en JSON, pour les exploiter dans sGTM. Si vous devez intégrer un système qui parle XML, cela peut vous éviter d’écrire cette conversion vous-même. Je m’arrête là pour le retour terrain, puisque je n’en ai pas.
Même chose pour Dedicated IP. Le principe est clair : faire sortir les requêtes du conteneur par une IP statique, notamment lorsqu’une API destinataire impose une liste d’IP autorisées. Il s’agit d’une option payante sur mesure, avec activation par Stape.
Ce n’est pas une fonctionnalité que je mettrais dans tous les setups. En revanche, si l’équipe qui gère votre API exige une IP fixe, c’est exactement le genre de détail qui passe soudain de « accessoire » à « condition de lancement du projet ».
Open Container for Bot Index : je reste peu convaincu pour mes usages
Open Container for Bot Index lève la restriction par défaut qui empêche les robots des moteurs de recherche d’accéder au conteneur.
Je comprends la fonction, mais je n’ai pas aujourd’hui de besoin suffisamment clair pour la recommander dans mes implémentations habituelles. Si votre configuration nécessite que ces robots accèdent à des ressources servies par sGTM, regardez-la. Sinon, je la laisserais de côté.
C’est aussi un avantage d’une approche modulaire : on peut parfaitement apprécier un outil sans devoir trouver une vocation personnelle à chacun de ses interrupteurs.
Request Delay et Schedule : à creuser, avec un scénario précis
Request Delay permet de différer le traitement d’événements entrants. Schedule déclenche des requêtes vers un chemin du conteneur à une fréquence horaire ou quotidienne.
Je vois des pistes intéressantes pour certains enrichissements : attendre qu’une information soit disponible dans un système tiers, ou déclencher périodiquement une opération. Mais je n’ai pas encore assez creusé ces fonctions pour vous vendre un retour d’expérience.
Surtout, attendre ne réalise pas l’enrichissement. Il faut encore récupérer la donnée, la rattacher au bon événement et prévoir ce qui se passe lorsqu’elle reste indisponible. Pour Schedule, il faut de la même manière construire le traitement déclenché. Ce sont des briques de temporisation, pas un workflow complet livré avec le café.
Data enrich : comprendre ce qui arrive dans le conteneur
User ID : intéressant techniquement, à examiner de près
Le power-up User ID génère un identifiant à partir de plusieurs signaux, dont l’IP, le user-agent, le hostname et des paramètres TLS. Il ne faut donc pas le confondre avec l’identifiant d’un compte connecté que votre application transmettrait volontairement.
L’intérêt recherché est une continuité d’identification lorsque les cookies sont limités. Mais je ne le présenterais pas comme intrinsèquement plus fiable que l’identification de GA4 : cela dépend du contexte, et les signaux utilisés peuvent changer ou être partagés par plusieurs visiteurs.
L’approche s’apparente à du fingerprinting et mérite une analyse spécifique avant activation. Le fait de hacher des signaux ne les rend pas automatiquement anonymes, et l’absence de cookie ne dispense pas d’examiner les règles applicables aux traceurs. La CNIL inclut le fingerprinting dans ce périmètre.
C’est donc une fonction que je traiterais au cas par cas, avec un besoin documenté et une validation adaptée. Certainement pas une case à cocher parce qu’elle est disponible.
Bot Detection : un de mes favoris
Bot Detection analyse les requêtes entrantes et fournit des signaux de détection, dont un score. On peut ensuite les exploiter dans le conteneur et les transmettre à un outil d’analytics.
Ce que j’aime, c’est le choix que cela donne : enrichir les événements avec un paramètre, filtrer certains envois, ou combiner les deux selon la destination.
Ma préférence est de commencer par observer. Remontez le signal, regardez les volumes concernés et les comportements associés, puis décidez des exclusions. Un score de détection reste un signal à évaluer ; filtrer trop largement peut aussi retirer du trafic légitime.
Pouvoir distinguer les visites suspectes aide à interpréter un taux de conversion ou une hausse de trafic. Avant de féliciter la campagne d’acquisition, c’est tout de même agréable de vérifier que son public n’est pas principalement constitué de scripts très motivés.
Ad Blocker Info : rendre visible une partie du problème
Ad Blocker Info ajoute un signal de présence d’adblocker via le header X-User-Adblocker. Il nécessite que Custom Loader soit déjà configuré.
Comme pour Bot Detection, je trouve l’information très utile à remonter dans l’analytics pour segmenter les événements et examiner les écarts de collecte. Cela permet de travailler avec un indicateur concret plutôt qu’avec l’explication universelle « ça doit être les adblockers ».
Il y a tout de même une limite à garder en tête : vous observez les requêtes qui arrivent. Si un visiteur est totalement invisible pour votre collecte, ce header ne va pas faire apparaître son existence. Le taux observé n’est donc pas une mesure exhaustive de l’équipement de tous vos visiteurs.
GEO Headers et User Agent Info : enrichir pour un usage identifié
GEO Headers ajoute des informations géographiques dérivées de l’IP. Cela peut servir à conditionner un traitement côté serveur, par exemple selon le pays estimé. Ce n’est pas une localisation exacte : un VPN, un réseau mobile ou une base imparfaite peuvent modifier le résultat.
User Agent Info expose des informations sur le navigateur, le système ou le type d’appareil sous forme de headers. C’est pratique pour segmenter ou diagnostiquer un comportement sans reconstruire soi-même toute la lecture du user-agent.
Dans les deux cas, je pars de la décision à prendre. Si le pays suffit, inutile de transmettre tous les détails géographiques à chaque destination. Si vous cherchez un bug spécifique à un navigateur, vous avez un usage précis des informations techniques. Enrichir parce qu’on peut enrichir finit surtout par produire des champs dont personne ne se souvient six mois plus tard.
Les logs et le monitoring : ce qui compte après la recette
Les power-ups attirent facilement l’attention, mais l’accès aux logs fait aussi partie de ce que j’apprécie chez Stape. Quand une donnée manque, pouvoir revenir aux requêtes est nettement plus utile que d’organiser une confrontation entre deux captures de dashboards.
Les logs Stape permettent d’examiner les flux entrants et sortants, les statuts et les détails disponibles pour comprendre où un envoi pose problème. La rétention dépend du plan : trois jours sur Pro, dix sur Business et Enterprise. L’export vers un stockage externe est proposé à partir d’Enterprise.
Cela aide à distinguer plusieurs situations : l’événement n’est pas arrivé, il est arrivé mais n’a pas produit l’envoi attendu, ou la plateforme destinataire a répondu avec une erreur. Ces cas peuvent donner le même résultat dans votre reporting, mais ils ne se corrigent pas au même endroit.
Le monitoring complète ce travail avec des règles d’alerte et des notifications par email. Il est disponible à partir de Business et nécessite l’activation des logs sortants. Je le trouve désormais bien pratique pour l’exploitation quotidienne.
Une réponse technique réussie ne valide toutefois pas le sens métier de la donnée. Une conversion avec le mauvais montant peut très bien être acceptée. C’est là que le monitoring natif et les contrôles personnalisés deviennent complémentaires.
Le premier vous aide à savoir si les échanges fonctionnent. Les seconds vérifient que vous n’envoyez pas consciencieusement n’importe quoi. J’ai une tendresse particulière pour ce deuxième problème, qui traverse les générations d’outils avec une remarquable stabilité.
Ce que je mettrais dans votre prochain setup
Si vous découvrez Stape, je vous conseille de commencer par un périmètre simple : choisir l’offre d’hébergement adaptée, estimer les requêtes, puis faire fonctionner un parcours complet avec Custom Loader. Vérifiez la collecte, le consentement et la réception par les destinations avant d’empiler les options.
Ensuite, examinez Cookie Keeper selon vos besoins de continuité, ajoutez les signaux Bot Detection et Ad Blocker Info pour comprendre le trafic, et prévoyez les logs et les alertes. Multi Domains, Anonymizer, File Proxy et les autres utilitaires viennent répondre aux contraintes particulières de votre projet.
« Oui, mais une bonne partie de tout ça, on pourrait la développer nous-mêmes. »
Bien sûr. La question est de savoir qui l’écrira, qui le testera et qui le maintiendra lorsque le navigateur ou l’API d’en face changera de comportement. Si vous avez cette capacité en interne et un besoin très spécifique, le développement maison peut être pertinent. Dans les autres cas, disposer de ces briques au même endroit a une valeur assez facile à comprendre.
C’est pour cela que je trouve l’étiquette « hébergement low cost » réductrice. Le prix compte, mais mon avis favorable vient surtout de l’accumulation de fonctions utiles : charger, traiter, sélectionner, diagnostiquer, surveiller. Tout ce qui fait qu’un setup reste exploitable une fois la mise en production passée.
Stape ne vous dispense pas de réfléchir à votre tracking. Il vous évite de reconstruire une partie de l’outillage nécessaire pour le faire correctement. Et personnellement, je trouve ça déjà très bien. J’ai suffisamment de choses à maintenir qui s’appellent final_v3.