Formation Tag Commander gratuite – 2026

Pourquoi repenser la gestion de vos tags ?

À l’ère des sites dynamiques, des single-page apps, du consentement RGPD et des multiples outils de tracking, la gestion des balises (ou « tags ») est devenue un enjeu central. Que ce soit pour envoyer des données vers Google Ads, Facebook CAPI, votre outil de web analytics ou votre CRM, tout repose sur une implémentation solide, centralisée, testable… et évolutive.

C’est exactement ce que permet un TMS (Tag Management System) comme TagCommander, proposé par Commanders Act. Grâce à lui, les balises ne sont plus dispersées dans le code source, mais regroupées au sein d’un conteneur unique, pilotable depuis une interface.

Dans ce guide, nous allons explorer ensemble toutes les étapes clés pour tirer parti de TagCommander dans une démarche structurée et professionnelle : de la configuration initiale à la gestion des règles, sans oublier les tests, le versioning et les bonnes pratiques de mise en production.

1. Poser les fondations : comprendre le rôle du conteneur TagCo

1.1. Le conteneur : votre centre de commandement

Le conteneur TagCommander est un fichier JavaScript que vous allez intégrer sur chaque page de votre site. Il contient tous les tags nécessaires à vos différents outils marketing ou analytics.

💡 Fini les balises éparpillées dans le HTML, vous centralisez tout ici.

Une fois configuré, ce conteneur est généré par l’interface Commanders Act et hébergé :

• soit via leur CDN (Content Delivery Network) avec un niveau de disponibilité garanti (SLA 100%),
• soit en local sur vos serveurs, si vous avez les ressources techniques pour en assurer la gestion.

Dans tous les cas, ce fichier doit être appelé sur toutes les pages à suivre, avec un timing crucial : il faut insérer le dataLayer (appelé tc_vars dans Tag Commander) en amont du conteneur, pour que les balises puissent utiliser ses variables.

1.2. Organiser son compte et ses conteneurs

Chaque organisation dispose d’un compte Commanders Act, dans lequel on crée un ou plusieurs conteneurs. Cette structure permet de découper votre tracking par domaine, sous-domaine, ou usage (ex. : conteneur principal + conteneur A/B testing).

Chaque conteneur est identifié par :

• un nom clair (souvent lié au projet ou au domaine),
• un ID numérique, visible à la fois dans la plateforme, dans l’URL de l’interface, et via la console du navigateur grâce à la méthode tC.containersLaunched.

Vous pouvez avoir plusieurs conteneurs actifs sur une même page, par exemple :

• un dans le <head> pour les outils critiques (A/B testing, performance),
• un dans le <body> pour les outils de tracking plus secondaires.

1.3. Le dataLayer (ou tc_vars) : socle de votre stratégie

Le dataLayer est un objet JavaScript baptisé ici tc_vars, qui contient toutes les données contextuelles de la page : type de page, ID utilisateur, montant du panier, catégorie produit, etc.

C’est à travers lui que les tags seront nourris.

Quelques points essentiels :

• Il doit être déclaré avant tout conteneur dans la page HTML.
• Il est sous forme d’objet clé/valeur : tc_vars['page_type'] = 'product';
• Sa structure doit être stable, documentée et partagée avec les développeurs.

Ce dataLayer devient l’interface de dialogue entre votre site et TagCommander. C’est lui qui permet d’éviter les bidouillages en dur dans les tags.

2. Les types de variables à connaître

Une fois votre conteneur installé, le cœur du pilotage passe par les variables. Ce sont elles qui vont permettre d’alimenter vos balises en données, de déclencher des événements ou de conditionner l’affichage d’un tag. TagCommander distingue plusieurs types de variables, chacune ayant un rôle bien défini.

2.1. Les variables externes

Les variables externes sont directement issues de votre dataLayer, c’est-à-dire de l’objet tc_vars que vous placez dans le code de votre site. Elles sont disponibles dès le chargement de la page, et servent à :

• Alimenter le contenu des balises (ex. : ID utilisateur, valeur du panier…)
• Définir des règles de déclenchement
• Créer des périmètres ou contraintes

Elles s’utilisent sous le format suivant : tc_vars['nom_de_la_variable'].

2.2. Les variables internes

Les variables internes sont générées directement par TagCommander, à partir d’éléments présents sur la page ou en combinant des données. Elles ne sont pas définies dans le dataLayer mais calculées à la volée, par exemple :

• Extraire une valeur d’URL ou d’un cookie
• Transformer une variable externe (ex. : montant TTC → HT)
• Créer une table de correspondance automatique

Elles sont accessibles avec le préfixe tC.internalvars. suivi du nom, ex. : tC.internalvars.page_type. Ce préfixe permet d’éviter tout conflit avec les autres types de variables.

2.3. Les variables d’événements

Ces variables d’événements sont utilisées pour envoyer des informations lors d’une interaction utilisateur, sans recharger la page. Par exemple : clic sur un bouton, ouverture d’une pop-up, progression dans un tunnel, etc.

Elles prennent la forme : tc_array_events['nom_de_la_variable'], et sont généralement déclenchées via des fonctions JavaScript appelées :

• tc_events (version 1, plus ancienne mais encore utilisée par quelques utilisateurs – on oublie cette méthode qui est totalement dépréciée)
• tC.event (version 2, moderne et absolument obligatoire en 2025)

Les variables d’événements sont essentielles pour suivre le comportement utilisateur en temps réel dans les SPAs ou les interfaces dynamiques.

2.4. Le Data Storage

TagCommander permet également d’utiliser un système de stockage de données via des cookies, appelé Data Storage. Vous pouvez y conserver temporairement certaines informations clés, comme :

• Un segment d’audience (ex. : test A/B)
• Un identifiant ou une préférence utilisateur
• La valeur d’une variable pour la réutiliser sur une autre page

Ce mécanisme est utile pour améliorer la personnalisation, suivre des parcours ou maintenir une cohérence dans le déclenchement des tags.

2.5 Initialiser correctement tc_vars avant chaque chargement de page

L’objet tc_vars joue un rôle central dans l’écosystème TagCommander : c’est le conteneur de données contextuelles qui alimente les balises, les déclencheurs et les périmètres. Il doit toujours être initialisé ou mis à jour avant le chargement du conteneur, et à chaque fois que le contexte de page change (par exemple dans une SPA).

Quand déclencher tc_vars ?

• 📍 Avant l’appel au fichier tc_XXXX_XX.js
• 🔁 À chaque changement de page dans une application en SPA

Voici un exemple générique d’objet tc_vars à intégrer dans votre code HTML :

<script>  
window.tc_vars = {
  env_work: "prod",
  lang: "fr",
  profil: "particulier",
  page_title: "Transmettre un capital",
  page_referrer: "https://www.exemple.fr",
  page_url: "https://www.xxx.fr/xxxx",    
  content_type: "Solution",
  rubrique: "Nos solutions"
};
</script>

💡 Important : si vous déclenchez un événement personnalisé comme tC.container.reload() (SPA), vous devez vous assurer que tc_vars a bien été mis à jour juste avant. Sinon, l’événement sera bien déclenché, mais les données envoyées seront incorrectes ou manquantes.

🚫 Erreur fréquente observée : le déclenchement de l’événement tC.container.reload() fonctionne, mais les balises ne reçoivent pas les bonnes données car tc_vars n’a pas été réinitialisé correctement.

3. Implémenter les fonctions d’événements

Sur un site moderne, tout ne se joue pas au chargement de la page. Beaucoup d’interactions ont lieu après coup : clic sur un bouton, affichage d’un pop-in, navigation sans rechargement (SPA), etc. Pour suivre ce type de comportements, TagCommander propose deux mécanismes de suivi événementiel, sous forme de fonctions JavaScript.

3.1. tc_events (version 1) – OBSOLETE A NE PAS LIRE SAUF SI VOUS ETES CONCERNE

Historiquement, les premiers événements étaient définis via la fonction tc_events. Cette version 1 est toujours supportée, mais elle est aujourd’hui obsolète. Chaque fonction est rattachée directement à un conteneur spécifique.

La syntaxe est la suivante :

tc_events_X(this, "ID", {
  'Variable1' : 'Valeur1',
  'Variable2' : 'Valeur2'
});

• X représente l’ID du conteneur
• ID est l’identifiant de l’événement
• Chaque variable est transmise sous la forme clé/valeur

Ces événements sont utiles pour envoyer des informations spécifiques à un moment donné, comme un clic ou une validation de formulaire, mais leur portée reste limitée à un seul conteneur.

3.2. tC.event (version 2, recommandée)

La version 2 introduit une fonction plus moderne et plus souple : tC.event. Elle permet de définir des événements globaux, réutilisables dans tous les conteneurs de votre compte, sans avoir à les rattacher individuellement.

Voici un exemple de syntaxe avec la V2 :

tC.event.monEvenement(this, {
  'click_type' : 'CTA',
  'page_path' : document.location.pathname
});

Cette méthode est aujourd’hui la plus utilisée. Elle permet la maintenance, la lisibilité du code et la réutilisation d’un événement dans plusieurs contextes.

Bon à savoir : la simple création d’un déclencheur personnalisé tC.event.monEvenement dans l’interface TagCommander suffit à « déclarer » cet événement, sans avoir besoin d’un bloc de code supplémentaire dans le conteneur.

Autre information pertinente : si vous ne déclarez pas l’événement dans l’interface Tag Commander mais que vous appelez la fonction tC.event.monEvenement vous aurez une erreur dans la console car l’événement n’aura pas été déclaré dans le conteneur.

3.3. API JavaScript cact() (version 3, la plus récente – 2025)

TagCommander propose une API JavaScript unifiée nommée cact() pour interagir dynamiquement avec les conteneurs, envoyer des événements, gérer la configuration, et écouter les changements de consentement. C’est une alternative moderne et souple à tC.event, compatible avec le SDK ou les conteneurs web.

Initialiser la configuration globale (siteId, sourceKey…)

Avant d’envoyer un événement ou d’interagir avec les services de Commanders Act, vous pouvez initialiser les paramètres avec :

cact('config', {
  siteId: 1234,
  sourceKey: 'ABCD-1234',
  collectionDomain: 'my.customdomain.com'
});

Tous les paramètres sont facultatifs si un conteneur TagCommander est déjà chargé sur la page.

Émettre un événement client (javascript) avec emit – en remplacement de tC.event (v2)

Idéal pour déclencher des balises personnalisées, suivre un clic, ou simuler une page vue :

cact('emit', 'page_view', { page_type: 'homepage' });

💡 emit est plus sécurisé que tC.event : il ne génère pas d’erreur si l’événement n’est pas encore déclaré.

Envoyer un événement serveur via trigger – UNIQUEMENT SERVER SIDE

Permet d’envoyer des données serveur-side vers Commanders Act. Chaque appel à trigger émet également un événement track_* utilisable comme déclencheur dans le TMS.

cact('trigger', 'purchase', {
  id: 'cmd-001',
  amount: 99.99,
  currency: 'EUR'
});

Obtenir le statut de consentement

Pour intégrer ou synchroniser avec TrustCommander :

cact('consent.get', function(result) {
  if (result.consent.status === "all-on") {
    console.log("Consentement total accepté");
  } else if (result.error) {
    console.warn("Erreur dans la récupération du consentement");
  }
});

Cas pratique : déclencher un script après mise à jour du consentement

cact('on', 'consent_updated', function(event) {
  console.log("Consentement mis à jour !");
  // relancer le suivi ou mettre à jour les scripts
});

Cette API unifiée te permet de centraliser tous tes événements, déclencheurs personnalisés et interactions avec la plateforme Commanders Act, sans dépendre du DOM ni de méthodes obsolètes.

En résumé :

• Utilisez tC.event majoritairement car bien documenté
• Gardez tc_events uniquement pour des intégrations existantes à maintenir

4. Créer et paramétrer ses tags

Une fois vos variables en place et vos événements définis, l’étape suivante consiste à créer les balises (tags) qui transmettront les données vers vos outils partenaires : analytics, marketing, A/B testing, etc. TagCommander vous permet de les gérer depuis une interface centralisée, que ce soit via des modèles préexistants ou en code personnalisé.

4.1. Types de tags disponibles

Lors de la création d’un tag, vous avez le choix entre :

• Un tag de la librairie : un modèle fourni pour les solutions courantes (Google Ads, Meta, AT Internet, etc.)
• Un tag personnalisé (custom) : si vous devez injecter un script sur mesure

Le processus est simple :

1. Cliquer sur « Ajouter un tag »
2. Choisir dans la librairie ou opter pour un tag custom
3. Nommer le tag
4. Insérer son contenu (script ou code HTML)
5. Définir les déclencheurs, la catégorie de confidentialité, etc.

4.2. Mapping des variables dans un tag

Une fois votre tag créé, il doit être alimenté avec les bonnes données. C’est là qu’intervient le mapping des variables, qui permet de relier dynamiquement les informations du dataLayer ou des événements à votre code.

Voici comment procéder :

1. Dans votre script, entourez les variables par des dièses #ma_variable#
2. Enregistrez : TagCommander détectera automatiquement les variables à mapper
3. Choisissez leur type (externe, interne, événement, data storage)

💡 Astuce : utilisez des noms en minuscule avec des underscores pour garder une convention claire (ex : #user_id# plutôt que #UserID#).

4.3. Personnalisation avancée

Les tags personnalisés vous offrent une grande liberté : vous pouvez écrire du JavaScript conditionnel, utiliser des boucles, tester des valeurs, etc. Voici quelques bonnes pratiques :

• Encapsulez votre code dans un bloc try / catch
• Ajoutez des console.log() pour tracer l’exécution
• Définissez clairement les règles de déclenchement pour éviter les conflits

Exemple de personnalisation :

var montant = #amount#;
if (montant > 100) {
  console.log("Tag déclenché pour un panier élevé");
  // ici votre code de tag
}

Cette flexibilité vous permet d’adapter chaque balise à votre contexte métier, sans surcharge côté développeurs.

🧩 Best process d’intégration de TagCommander sur votre site

Voici les étapes à suivre pour intégrer correctement TagCommander dans votre environnement web, que ce soit en environnement de recette ou en production. Ces actions permettent de garantir une collecte de données fiable et structurée.

1. Intégrer le conteneur TagCommander Ajoutez le <script> principal généré par l’interface TagCommander sur l’ensemble des pages du site. ⚠️ L’URL du conteneur doit être adaptée selon l’environnement :
   • Environnement de recette : conteneur dédié ou version non publiée
   • Environnement de production : conteneur live validé et déployé

🔧 Intégration du conteneur TagCommander selon l’environnement

Pour que TagCommander fonctionne correctement dans tous vos environnements (production, recette, préproduction, staging…), vous devez appeler la bonne version du conteneur JavaScript selon le contexte.

📌 Où intégrer ce script ? Placez-le le plus haut possible dans la balise <head> de toutes vos pages. Cela garantit que les balises puissent s’exécuter rapidement et correctement.

Exemple de script à intégrer :

<!-- Environnement de PRODUCTION -->
<script src="https://cdn.tagcommander.com/xxxx/tc_xxxx_xx.js"></script>

<!-- Environnement de RECETTE / PREPROD / STAGING -->
<script src="https://cdn.tagcommander.com/xxxx/uat/tc_xxxx_xx.js"></script>

🚫 Attention : Ne pas respecter cette règle d’environnement peut bloquer ou fausser la collecte de données. Erreur fréquente : appeler la version production /tc_xxxx_xx.js même en recette, ou oublier le /uat/ dans les environnements de test.

1. Initialiser le tc_vars avant le conteneur Le dataLayer de TagCommander doit être déclaré au-dessus du script du conteneur. Il doit contenir les variables nécessaires au plan de marquage (ex : page type, user ID, montant panier, etc.). Exemple : window.tc_vars = { page_type: "homepage", user_id: "123456", cart_value: "89.99" };
2. Gérer les vues “virtuelles” dans un parcours SPA Pour les pages affichées dynamiquement sans rechargement (Single Page Application), il est nécessaire de forcer TagCommander à redéclencher une “page vue” à chaque changement d’état de page. Concrètement : : ex pageview : Ce mécanisme permet de suivre précisément les interactions utilisateur sur les pages dynamiques comme.
   • Réinitialiser les variables tc_vars
   • Déclencher un nouvel événement virtuel via tC.event

Forcer une page vue virtuelle dans un parcours SPA

Dans les parcours web qui fonctionnent en mode Single Page Application (SPA), les changements de page ne provoquent pas de rechargement complet du navigateur. Résultat : TagCommander ne détecte pas automatiquement qu’une “nouvelle page” vient d’être affichée.

Pour corriger cela, il est nécessaire de :

1. Réinitialiser / mettre à jour tc_vars avec les nouvelles valeurs (page_type, ID page, etc.)
2. Déclencher manuellement une page vue virtuelle en appelant :

tC.container.reload({ events: { pageview: [{}, {}] } });

Cette ligne permet de simuler une nouvelle page vue et de relancer le déclenchement des tags qui dépendent du chargement de page.

🚫 Attention : Vous devez impérativement réactualiser tc_vars avant d’appeler tC.container.reload().

Dans certains cas observés en environnement de recette, l’événement est bien déclenché, mais les données envoyées sont obsolètes ou vides, car tc_vars n’a pas été correctement mis à jour.

1. Implémenter les événements & attributs personnalisés Selon les règles métier de votre plan de marquage, vous devez intégrer :Ces éléments doivent être mis en place conditionnellement selon les pages, les parcours utilisateurs ou les actions spécifiques définies dans le plan de taggage.
   • Des événements personnalisés via tC.event.nom
   • Des attributs HTML utilisés comme déclencheurs ou variables (via le DOM)

5. Définir les règles de déclenchement

Une balise ne doit pas se déclencher n’importe quand. Pour éviter les erreurs de tracking ou la surconsommation de ressources, TagCommander vous permet de définir précisément quand, où et à quelles conditions un tag doit s’activer. Cela se fait à travers trois éléments clés : les déclencheurs, les périmètres et les contraintes.

5.1. Les déclencheurs

Le déclencheur est l’événement de base qui active un tag. Il peut s’agir de :

• Le chargement du conteneur
• Le DOM prêt (structure HTML terminée)
• Un clic sur un bouton (via un sélecteur CSS)
• La soumission d’un formulaire
• Un scroll de la page
• Un événement personnalisé (tC.event.nom)

Vous pouvez en associer plusieurs à un même tag. Dans ce cas, la logique est OU : si l’un d’eux se déclenche, le tag s’exécute.

5.2. Les périmètres

Le périmètre permet de définir le contexte dans lequel un tag peut être exécuté. C’est une couche de filtrage complémentaire aux déclencheurs. Les options sont variées :

• URL (fixe ou avec pattern)
• Valeur de variable (externe, interne, événement)
• Cookie spécifique
• Type de navigateur ou d’appareil
• Audience issue de DataCommander
• Conditions avancées via le menu « Advanced »

💡 Par exemple, vous pouvez déclencher un tag uniquement sur les pages produits, ou uniquement sur mobile.

Là aussi, plusieurs périmètres = logique OU.

5.3. Les contraintes

Les contraintes permettent d’ajouter un niveau de condition supplémentaire… mais avec une logique ET. C’est-à-dire que toutes les contraintes doivent être vraies pour que le tag soit autorisé à se lancer.

Les contraintes utilisent les mêmes types de conditions que les périmètres (URL, cookie, device, variable, etc.), mais servent à affiner davantage l’exécution.

Exemple combiné : Un tag déclenché à la fois :

• au clic sur un bouton (déclencheur)
• uniquement si l’URL contient /checkout (périmètre)
• et si le consentement tracking est donné (contrainte sur une variable Privacy)

Bonnes pratiques

• Vérifiez si un déclencheur ou périmètre existe déjà avant d’en créer un nouveau (évite les doublons)
• Donnez des noms explicites à chaque élément pour faciliter la maintenance
• Testez vos règles sur un environnement de recette avant de passer en production

6. Générer et organiser ses versions

Dans TagCommander, toute modification (ajout de tag, changement de variable, nouvelle règle…) nécessite une étape clé : la génération d’une version. C’est ce qui va permettre de produire un fichier de conteneur mis à jour, prêt à être testé puis déployé. Cette gestion par version est essentielle pour assurer une traçabilité, une stabilité et une réversibilité de vos évolutions.

6.1. Génération d’une version

Pour générer une nouvelle version, vous devez d’abord valider les modifications apportées dans l’interface. Lors de la génération, plusieurs options vous sont proposées :

• Réorganiser l’ordre des tags (certains doivent se charger avant d’autres)
• Activer ou désactiver des balises sans les supprimer
• Définir un timeout pour les tags trop lents (amélioration des performances)
• Activer/désactiver la gestion Privacy sur la version

💡 Conseil : placez en haut de la liste les tags critiques (comme ceux liés à la conversion ou au consentement).

6.2. Historisation et organisation

Chaque version créée est enregistrée avec :

• Son numéro de version
• Sa date de création
• Son statut (déployée ou non / en production ou non)
• Le nom de la personne qui l’a générée
• Un libellé descriptif (à renseigner avec soin !)

Le libellé est très important : il doit permettre de comprendre rapidement le contenu de la version, surtout en cas de rollback.

6.3. Bonnes pratiques de versioning

• Utilisez une convention claire pour vos noms de versions : Nom du tag – Action – Périmètre – Description
• Indiquez le type de modification : Création, Modification, Suppression
• Évitez de regrouper trop de changements critiques dans une seule version
• En cas de risque, ajoutez la mention NE PAS DÉPLOYER dans le libellé pour alerter les autres utilisateurs

Ce système de version est aussi utile en cas de problème : vous pouvez à tout moment revenir à une version antérieure, déjà testée et validée.

7. Tester avant production

Un bon plan de marquage ne s’arrête pas à la configuration. Avant de déployer en production, il est essentiel de valider chaque élément : balises, variables, déclencheurs, scripts… Une erreur non détectée en recette peut fausser vos données, voire bloquer certaines fonctionnalités du site. TagCommander propose une interface de test complète pour sécuriser vos déploiements.

7.1. Les 5 niveaux de test

Chaque version peut (et doit) être testée à plusieurs niveaux :

• Conteneur : vérification du fichier JavaScript global
• Data Layer : contrôle des variables (externes, internes, événements…)
• JavaScript statique / dynamique : validation des blocs personnalisés
• Tags : test individuel de chaque balise intégrée
• Événements : vérification des événements tc_events et tC.event

Chaque test donne lieu à une validation (✅), une erreur (❌) ou une absence de test (–). Une erreur bloquante rend la version non-déployable.

7.2. Utiliser les environnements de test

TagCommander permet de configurer des environnements de test, simulant les conditions de production (mêmes variables, mêmes balises, mêmes valeurs). Cela permet de :

• Tester sans impacter les données réelles
• Reproduire les comportements utilisateurs avec des valeurs réalistes
• Identifier plus facilement les anomalies

Chaque environnement peut être lié à un ou plusieurs conteneurs, et alimenté avec des jeux de variables externes spécifiques.

7.3. Résoudre les erreurs de manière efficace

Lorsqu’une erreur est détectée, il est conseillé de suivre une approche structurée :

1. Commencer par les erreurs liées aux variables (dataLayer)
2. Vérifier ensuite les scripts JavaScript (custom ou dynamiques)
3. Poursuivre avec les balises, puis les événements
4. Terminer avec le conteneur global

🛠️ Aide au testing du plan de tags Tag Commander : logger les events facilement

Pour faciliter la validation des événements déclenchés via tC.event (V2), vous pouvez utiliser le script suivant directement dans la console de votre navigateur (onglet Console des DevTools). Il vous permettra d’afficher en temps réel les événements qui se déclenchent, ainsi que les données qui leur sont associées :

(function monitorTCEEvents() {
  const interval = setInterval(() => {
    if (typeof tC !== "undefined" && typeof tC.event === "object") {
      Object.keys(tC.event).forEach(eventName => {
        const originalHandler = tC.event[eventName];
        if (typeof originalHandler === "function") {
          const backup = `__originalHandler_${eventName}`;
          window[backup] = originalHandler;

          tC.event[eventName] = function (...args) {
            window[backup](...args);
            console.group("📊 Custom Event Triggered");
            console.log(`%ctC.event.${eventName}`, "background: #3A86FF; color: #fff; padding: 2px 6px; border-radius: 3px;", "fired");
            if (args[1]) {
              console.table(args[1]);
            } else {
              console.log("No data passed to event.");
            }
            console.groupEnd();
          };
        }
      });

      clearInterval(interval);
    }
  }, 100);
})();

Comment l’utiliser :

1. Ouvrez la console (F12 ou clic droit → “Inspecter”)
2. Collez le script ci-dessus dans l’onglet Console
3. Interagissez avec le site (clics, pop-ups, etc.) pour voir les événements s’afficher

C’est un outil très utile pour vérifier que vos déclenchements tC.event sont bien pris en compte dans l’interface.

Vous ne voyez pas vos console.log dans la console, pourquoi ?

Lorsque vous ajoutez un console.log dans une balise (tag) pour vérifier si elle se déclenche correctement ou pour inspecter une valeur

Lorsqu’une nouvelle version du conteneur est générée, le console.log est automatiquement réécrit en tC.log.

Pour pouvoir lire ces tC.log dans votre navigateur, vous devez ajouter un cookie spécifique :

tC.setCookie("tCdebugLib", 1, 30);

Bonnes pratiques

• Ne déployez jamais une version contenant une croix rouge ❌ dans le tableau de tests
• Utilisez des console.log() dans vos balises custom pour identifier les erreurs rapidement
• Testez toujours sur différents navigateurs / devices si votre site est responsive ou multi-support

8. Déployer proprement en production

Une fois vos tests validés, place au grand moment : le déploiement. Dans TagCommander, le déploiement consiste à rendre une version « live » sur votre site, c’est-à-dire à diffuser le nouveau conteneur vers les utilisateurs finaux. Cette étape est sensible : une erreur peut impacter les données collectées ou la performance du site. D’où l’importance de suivre une méthode rigoureuse.

8.1. Checklist avant mise en production

Avant de cliquer sur « Déployer », vérifiez ces points :

• Tous les tests sont au vert ✅ (pas de croix rouges dans le tableau de recette)
• Les libellés de version sont clairs et documentés
• Les balises critiques sont bien en haut du conteneur
• Les déclencheurs, périmètres et contraintes sont correctement configurés
• La Privacy est activée si nécessaire
• Si Privacy, les balises sont conditionnées aux catégories de consentement souhaitées

8.2. Méthodes de déploiement et rollback

TagCommander vous permet de :

• Déployer la dernière version générée
• Revenir en arrière avec une version précédente (rollback)
• Visualiser les changements effectués depuis le dernier déploiement

💡 Conseil : testez toujours en environnement de recette avant de basculer en prod. Et si possible, évitez les mises en production en fin de journée ou la veille d’un jour férié.

9. Maintenir une installation propre

Une fois votre conteneur en production, le travail n’est pas terminé pour autant. Comme tout système technique, une configuration TagCommander nécessite de l’entretien régulier. Sans cela, les doublons s’accumulent, les règles deviennent illisibles, et le poids du conteneur explose… au détriment des performances et de la qualité des données.

9.1. Suivi des modifications

TagCommander propose un historique complet des actions réalisées sur chaque conteneur. Vous pouvez ainsi savoir :

• Qui a modifié quoi et quand
• Combien de fois un élément a été modifié
• Quels types d’actions ont été effectués (ajouts, suppressions, mises à jour…)

💡 Utilisez les filtres par mot-clé (ex : added, updated) pour retrouver facilement une opération spécifique.