> For the complete documentation index, see [llms.txt](https://doc.commandersact.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.commandersact.com/fr/developpeurs/commanders-tag-gateway.md).

# Commanders Act Gateway

Ce document décrit comment déployer **Commanders Act Gateway**, une **gateway first-party unifiée** qui utilise **une configuration unique et un seul chemin sur votre domaine** pour alimenter plusieurs cas d’usage de tracking et d’hébergement.

Commanders Act Gateway inclut **Google Tag Gateway**, mais n’est **pas limité à Google**.\
Il est conçu pour servir et collecter des données pour **tous vos partenaires marketing et analytics**, en utilisant la même infrastructure first-party.

Une seule configuration, un seul chemin first-party, trois usages :

* Google Tag Gateway (GA4, Google Ads)
* Tracking first-party vers toutes les destinations server-side
* Hébergement first-party de bibliothèques Third-party

Si votre objectif est d’implémenter Google Tag Gateway, vous êtes au bon endroit.\
Si votre objectif est de construire une architecture first-party durable et agnostique vis-à-vis des fournisseurs, vous êtes aussi au bon endroit.

<figure><img src="https://1259070148-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Mk6XpTQ2LaRLcr2tA-d%2Fuploads%2Fgit-blob-5c269a1cb309c24a7504446eef7a53b7aafd97d9%2Fschema_google_ads%20(4).png?alt=media" alt=""><figcaption></figcaption></figure>

***

## Pourquoi utiliser Commanders Gateway ?

### 1. Avantages de l’utilisation d’un gateway

Une configuration gateway améliore **la qualité et l’exhaustivité de la collecte de données** sur l’ensemble de votre stack marketing.

* Les scripts des fournisseurs sont servis depuis votre propre domaine, ce qui réduit la probabilité qu’ils soient bloqués par des adblockers.
* Les restrictions du navigateur (comme l’ITP de Safari) limitent ou bloquent souvent les Third-party cookies et certains cookies JavaScript 1st party, mais avec une configuration first-party server-side, la mesure reste plus fiable.
* Cela garantit **un tracking plus précis**, en fournissant aux partenaires des signaux de meilleure qualité pour la mesure, l’attribution et l’optimisation.

### 2. Avantages d’utiliser Commanders Gateway

En plus des avantages de toute approche gateway, **Commanders Gateway** apporte des avantages uniques :

* Pas limité à Google Tag Gateway — la même configuration durable s’applique à **tous vos partenaires** (Meta, Snapchat, Bing, Awin, etc.).
* Configuration unifiée : un **chemin unique** (`/mypath`) sert et relaie toutes les bibliothèques des fournisseurs.
* Des noms de fichiers JavaScript obfusqués sont automatiquement fournis par Commanders Act, ce qui rend leur détection par les listes de blocage bien plus difficile.
* Avec le même chemin simple, vous pouvez aussi activer d’autres **fonctionnalités d’hébergement et de tracking first-party** telles que : l’hébergement de vos conteneurs de tag management, le tracking server-side des événements, ou les statistiques CMP anonymes. Une configuration unique alimente tout votre système d’hébergement et de tracking first-party.
* Une configuration centralisée simplifie le déploiement et la maintenance tout en restant **pérenne** face aux futures restrictions des navigateurs.

***

## Vue d’ensemble

**Commanders Gateway** vous permet de déployer des tag marketing et de mesure en utilisant votre **propre infrastructure first-party**, hébergée sur le domaine de votre site web.\
Cette infrastructure se situe entre votre site web et les services de vos partenaires (Google, Meta, Bing, Snapchat, Awin, etc.).

Avec Commanders Gateway :

* Les bibliothèques Google (gtag.js / gtm.js) sont chargées directement depuis votre **domaine first-party**.
* Les autres bibliothèques fournisseurs sont servies depuis `/mypath/js/` à l’aide de **noms de fichiers obfusqués**.
* Toutes les requêtes de mesure sont relayées via votre domaine avant d’être transmises aux endpoints des partenaires concernés.

***

## Google Tag Gateway (GTG) et consent

{% hint style="info" %}
Cette section est rédigée pour la vérification des prérequis du Consent Mode avec Google Tag Gateway (GTG). Elle explique ce que GTG change pour le consent, comment vérifier l’inscription, et quoi faire si un signal de consent "late" est détecté sur un domaine inscrit à GTG.&#x20;
{% endhint %}

#### Ce que Google Tag Gateway change pour le consent

**Google Tag Gateway (GTG) pour les annonceurs** permet à un site web de servir des tag Google (`gtag.js`, `gtm.js`) depuis le propre domaine first-party du site au lieu de `googletagmanager.com`, en utilisant un CDN, un load balancer ou un web server. Commanders Act Gateway peut être utilisé pour implémenter GTG (voir [Architecture](#architecture) ci-dessous).

GTG ne change pas *ce que* fait le consent mode — il change **d’où le Google tag est servi et, surtout, quand il peut se charger par rapport à votre bannière de consent**. C’est ce timing qui a un impact sur le consent :

* **Injection CDN automatisée / en un clic** (la configuration dans l’interface proposée par Google pour Cloudflare, Akamai, Fastly ou un Google Cloud Load Balancer) amène Google à injecter directement la règle de routage dans la configuration de votre CDN ou load balancer, plaçant généralement le Google tag très tôt dans la page. Comme cette injection se produit **en dehors de votre tag management ou du code source de la page**, vous ne pouvez généralement plus **contrôler l’ordre de chargement des scripts** par rapport à votre bannière de consent. Si le stub de consent de votre CMP n’a pas encore été exécuté et défini les états de consent par défaut, le Google tag peut se déclencher en premier.
* **Configuration GTG manuelle / en self-service**, où vous configurez vous-même le routage et référencez directement le script first-party dans le code source de votre page, laisse l’ordre de chargement des scripts sous votre contrôle — vous décidez si le Google tag ou le script de consent de votre CMP se charge en premier.

Lorsqu’un Google tag se déclenche avant que votre CMP ait défini un état de consent par défaut, Google appelle cela un **signal de consent "late"**: le tag s’exécute avec un état de consent inconnu/non défini au lieu de respecter le défaut que votre CMP était censée définir. Cela peut amener les tags à se comporter comme si aucun framework de consent n’était présent, et c’est signalé par les outils de diagnostic de Google (voir [Vérification](#verification-checklist) ci-dessous).

{% hint style="warning" %}
Revenir en arrière sur GTG est **pas** la méthode recommandée pour résoudre un signal de consent late : cela fait perdre les avantages de durabilité de la mesure first-party que GTG est conçu pour offrir. Les remédiations recommandées sont décrites dans [Si un signal de consent late est détecté](#if-a-late-consent-signal-is-detected-and-gtg-enrollment-is-confirmed) ci-dessous.&#x20;
{% endhint %}

#### La documentation de Google sur GTG

* [Google tag gateway for advertisers – vue d’ensemble](https://developers.google.com/tag-platform/tag-manager/gateway)
* [Configurer Google tag gateway for advertisers](https://developers.google.com/tag-platform/tag-manager/gateway/setup-guide)

#### Vérifier si un tag est inscrit à GTG

Avant d’examiner un problème de consent lié à GTG, confirmez si le domaine est réellement inscrit. L’une des méthodes suivantes peut être utilisée :

* **Dans l’interface produit Google** — Dans Google Tag Manager, allez à **Admin → Google tag gateway**. Chaque domaine est listé avec un statut : `First-party` (GTG est actif), `Non démarré` (GTG n’a pas été activé), ou `Domaines activés` pour les domaines configurés manuellement ou via un tag différent. Le même statut est disponible sur l’écran équivalent dans Google Ads et Google Analytics.
* **Google Tag Assistant** — Connectez Tag Assistant au site web, déclenchez les tag pertinents, et vérifiez d’où les requêtes du Google tag sont réellement servies et vers où elles sont envoyées (**Summary → Output → Hits Sent**). Si les requêtes du Google tag sont routées vers votre propre domaine (par exemple `example.com/mypath/` ou `example.com/gtag/js`) au lieu de `www.googletagmanager.com` ou `www.google-analytics.com`, GTG est actif pour cette page.
* **Outils de développement du navigateur** — Dans l’onglet Network, vérifiez si le script et les requêtes de mesure pour `gtag.js` / `gtm.js` proviennent de votre domaine first-party plutôt que d’un domaine Google.

#### Si un signal de consent "late" est détecté et que CAGT est confirmé

Un signal de consent late apparaît généralement dans les [outils de débogage du consent](https://developers.google.com/tag-platform/security/guides/consent-debugging) (chronologie de consent de Tag Assistant, ou avertissement dans la console) comme le Google tag qui se déclenche avant qu’un état de consent par défaut ne soit défini, ou un état de consent signalé comme "unknown" au moment où le tag s’est déclenché.

**Une fois que vous avez confirmé à la fois (a) un signal de consent late, et (b) que GTG est inscrit sur le domaine**, Google recommande l’une des approches de remédiation suivantes :

1. **Adoptez Advanced Consent Mode** dans votre configuration CMP Commanders Act, et configurez **Data Transmission Controls** et **Global Consent Defaults** dans les paramètres de votre Google tag (Google Ads, GA4 ou Campaign Manager 360) selon vos besoins de conformité. C’est le mécanisme que Google recommande spécifiquement pour les tag activés avec GTG — voir [pourquoi ci-dessous](https://claude.ai/chat/4300c170-a117-4d9d-ae3c-86117d316787#why-advanced-consent-mode-u+c-is-recommended-for-gtg).
2. **Migrez tous vos Google tag dans un seul conteneur Google Tag Manager, et déployez ce conteneur lui-même via GTG**, au lieu d’injecter des tag gtag.js individuels. Cela centralise le contrôle de l’ordre de chargement dans GTM, de sorte que les vérifications de consent intégrées de GTM s’appliquent à chaque Google tag dans le conteneur, quelle que soit la manière dont le script du conteneur est routé.
3. **Configurez GTG manuellement**, afin que vous — et non une injection CDN automatisée — contrôliez l’emplacement de la référence du script GTG first-party dans le code source de votre page, par rapport au script de bannière de consent Commanders Act.

{% hint style="info" %}
Ces trois options ne s’excluent pas mutuellement. Par exemple, une configuration GTG manuelle (option 3) peut être combinée avec Advanced Consent Mode (option 1) pour une résilience supplémentaire si l’ordre de chargement est un jour affecté par une évolution future de la page ou du CDN.&#x20;
{% endhint %}

**Pourquoi Advanced Consent Mode est recommandé pour GTG**

Advanced Consent Mode est le mécanisme que Google recommande pour les tag activés avec GTG car, contrairement à Basic Consent Mode (qui bloque simplement le tag jusqu’à ce qu’un défaut soit défini), il est **compatible avec les configurations GTG manuelles**: il permet au Google tag de se charger et d’envoyer des pings sans cookie et conformes à la vie privée même lorsque le consent est refusé ou pas encore connu, puis passe à la mesure complète dès que le choix du visiteur est reçu — sans dépendre de l’ordre exact de chargement du script GTG et de la bannière de consent.

Pour l’activer avec Commanders Act :

* Activer **Advanced Consent Mode** dans votre configuration Google Consent Mode de Commanders Act — voir [Google Consent Mode in Commanders Act TMS](https://doc.commandersact.com/features/consent-management/setup-guides/tag-manager/google-consent-mode-in-commanders-act-tms) et [Google Tag Manager (GTM) – Consent Mode](https://doc.commandersact.com/features/consent-management/setup-guides/tag-manager/google-tag-manager-gtm-consent-mode).
* Activer **Data Transmission Controls** dans les paramètres de votre Google tag (Google Ads, GA4 ou Campaign Manager 360) pour restreindre indépendamment les données publicitaires, analytics et de diagnostic lorsque le consent est refusé — voir [Data transmission controls](https://support.google.com/google-ads/answer/16054531).
* Définir **Global Consent Defaults** pour votre Google tag afin qu’un état de consent de référence (refusé, sauf exigence contraire) s’applique toujours par région, même dans le rare cas où l’on ne peut pas garantir que le stub de la CMP s’exécute en premier — voir la [section sur le comportement spécifique à la région du guide Google sur le consent mode](https://developers.google.com/tag-platform/security/guides/consent#region-specific_behavior) et [les paramètres Consent Overview de GTM](https://support.google.com/tagmanager/answer/10718549?hl=en).

{% hint style="success" %}
Choisissez le bon template ! Si vous devez activer Google Consent Mode avec IAB TCF, utilisez notre TCF IAB [templates de bannière](https://doc.commandersact.com/features/consent-management/user-guides/privacy-banners/banner-templates) (Footer ou Popin) et suivez les [spécifications de configuration mentionnées ici](https://doc.commandersact.com/features/consent-management/setup-guides/tag-manager/google-consent-mode-in-commanders-act-tms#additional-settings)
{% endhint %}

***

## Architecture

Avec **Commanders Gateway**, vous réservez un **chemin unique** sur votre domaine, par exemple :

```
https://example.com/mypath/
```

* **Scripts Google** (gtag.js / gtm.js) sont chargés directement depuis `/mypath/`.
* **Autres scripts fournisseurs** (Meta, Snapchat, Bing, Awin, etc.) sont servis depuis `/mypath/js/` avec un **nom de fichier obfusqué** généré par Commanders Act.

Exemple :

```
https://example.com/mypath/js/f4558899203.js
```

La correspondance entre chaque fournisseur et son nom de fichier de script obfusqué est fournie dans l’ **interface Commanders Act First-Party Hosting**.

**Schéma (conceptuel) :**

```
Site web  →  example.com/mypath/ (Google tags)
         →  example.com/mypath/js/f4558899203.js (Meta, Snap, Bing…)
         →  Commanders Gateway  →  endpoint du fournisseur
```

***

## Filtrage et gouvernance des cookie

Certaines organisations, en particulier celles ayant des politiques de confidentialité strictes, peuvent s’inquiéter de l’envoi de **cookie first-party vers des partenaires externes** comme Google. Commanders Gateway prend en charge **la minimisation des données** et fournit des mécanismes pour contrôler quels cookie peuvent transiter via le gateway. Deux approches complémentaires peuvent être utilisées :

#### Liste noire de cookie à l’edge

Les clients peuvent filtrer les cookie **directement au niveau du CDN ou de la couche edge** (Cloudflare Worker, Fastly Compute, etc.). Cela peut être fait en **configurant simplement le code Worker fourni dans ce guide** (voir l’onglet CloudFlare free ou Faslty ci-dessous) afin de supprimer des cookie spécifiques avant que la requête ne soit transmise à Commanders Gateway.

Cela permet de supprimer des cookie spécifiques de la requête **avant qu’elle n’atteigne Commanders Gateway**, garantissant que seuls les cookie approuvés par l’organisation quittent son infrastructure.

#### Liste blanche de cookie avant transmission aux partenaires

Commanders Gateway peut également imposer **une liste blanche de cookie lors de la transmission des requêtes aux partenaires**.

Par exemple, lors de la transmission de requêtes de mesure à Google, le gateway peut être configuré pour **inclure uniquement les cookie liés à Google** (tels que `_ga` ou `_gcl_*`).\
Tous les autres cookie sont automatiquement exclus de la requête envoyée à Google.

## Avant de commencer

Ce guide suppose que votre site web est déjà configuré avec :

* Un système de tag management (Commanders Act, Google Tag Manager ou équivalent).
* Un CDN ou load balancer (Cloudflare, Akamai, Fastly, Nginx, etc.) capable de transmettre des requêtes vers des endpoints externes.

***

## Étape 1 : Choisir le chemin de diffusion du tag

Vous devez réserver **un chemin** sur le domaine de votre site web.

Exemple :

```
/mypath
```

Attention : cette configuration redirige tout le trafic correspondant au chemin choisi. Pour éviter d’affecter votre site web, choisissez un chemin qui n’est pas déjà utilisé.

***

## Étape 2 : Router le trafic

{% tabs %}
{% tab title="Cloudflare Enterprise" %}
Lorsque vous utilisez Cloudflare Enterprise, nous recommandons d’utiliser un **Cloudflare Worker** pour proxyer tout le trafic provenant du chemin choisi, par exemple `/mypath`, vers l’infrastructure Commanders Gateway.

Cette approche est la même que la configuration Cloudflare Free. Elle est plus fiable que d’essayer de router le chemin avec Cloudflare Origin Rules, car le Worker offre un contrôle total sur l’URL de la requête, les en-têtes, le filtrage des cookie et la transmission de la géolocalisation.

**Étape 1 : Créer le Worker**

1. Dans le Dashboard Cloudflare, allez à **Workers & Pages** → **Créer une application** → **Worker**.
2. Copiez/collez le code suivant :

```javascript
const prefix = "/mypath"; // Chemin d’exemple, remplacez-le par le chemin choisi à l’étape précédente
const sid = "12345"; // ID d’espace de travail d’exemple (alias site ID), remplacez-le par votre propre ID

// Liste des noms de cookie qui ne doivent PAS être transmis à Commanders Gateway. Vous pouvez ajouter vos cookie techniques si nécessaire
const blacklistedCookies = [
  "PHPSESSID",
  "JSESSIONID"
];

addEventListener("fetch", event => {
  event.respondWith(handleRequest(event.request));
});

function filterCookieHeader(cookieHeader, blacklist) {
  if (!cookieHeader) return "";

  const blacklistSet = new Set(blacklist);

  const filteredCookies = cookieHeader
    .split(";")
    .map(cookie => cookie.trim())
    .filter(cookie => {
      const cookieName = cookie.split("=")[0];
      return !blacklistSet.has(cookieName);
    });

  return filteredCookies.join("; ");
}

async function handleRequest(request) {
  const url = new URL(request.url);

  if (url.pathname.startsWith(prefix)) {
    // Construire l’URL cible. Elle remplace ${sid} par l’ID de votre espace de travail/site ci-dessus.
    const targetUrl = `https://s${sid}.commander4.com${url.pathname}${url.search}`;

    // Cloner les en-têtes de la requête
    const newHeaders = new Headers(request.headers);
    newHeaders.set("X-Forwarded-Host", url.host);

    const country = request.cf?.country || "";
    const region = request.cf?.region || "";

    if (country) newHeaders.set("X-Forwarded-Country", country);
    if (region) newHeaders.set("X-Forwarded-Region", region);
    if (country && region) {
      newHeaders.set("X-Forwarded-CountryRegion", `${country}-${region}`);
    }

    // Filtrer l’en-tête Cookie avant de proxyer la requête.
    const cookieHeader = newHeaders.get("Cookie");
    const filteredCookies = filterCookieHeader(cookieHeader, blacklistedCookies);

    if (filteredCookies) {
      newHeaders.set("Cookie", filteredCookies);
    } else {
      newHeaders.delete("Cookie");
    }

    // Supprimer l’en-tête Host pour éviter les conflits
    newHeaders.delete("host");

    // Proxyer la requête vers l’infrastructure Commanders Gateway
    const proxyRequest = new Request(targetUrl, {
      method: request.method,
      headers: newHeaders,
      body: request.body,
      redirect: "follow"
    });

    return fetch(proxyRequest);
  }

  return new Response("Not Found", { status: 404 });
}
```

Ce Worker proxy les requêtes tout en ajoutant des en-têtes supplémentaires :

* `X-Forwarded-Host`
* `X-Forwarded-Country`
* `X-Forwarded-Region`
* `X-Forwarded-CountryRegion`

Il peut aussi filtrer les cookie sensibles ou techniques avant de transmettre la requête à Commanders Gateway.

**Étape 2 : Associer le Worker au chemin**

1. Dans Cloudflare, ouvrez les paramètres de votre domaine.
2. Accédez à **Workers Routes**.
3. Ajoutez une nouvelle route avec :
   * **Motif d’URL**: `www.example.com/mypath*`
   * **Worker**: sélectionnez le Worker créé à l’étape 1.

Une fois enregistré, toutes les requêtes vers `/mypath` seront proxyées vers Commanders Gateway.

**Étape 3 : Vérifier la configuration**

Vous pouvez vérifier la configuration en accédant à :

```
https://example.com/mypath/g/healthy
```

Note : le sous-chemin google par défaut est /g/ mais il peut être personnalisé. Ce sous-chemin google se trouve immédiatement après /mypath/ .

Il devrait renvoyer :

```
ok
```

Pour vérifier la transmission de la géolocalisation, vous pouvez aussi tester :

```
https://example.com/mypath/g/?validate_geo=healthy
```

Il devrait aussi retourner :

```
ok
```

{% endtab %}

{% tab title="Cloudflare Snippet" %}
Cloudflare Snippets offrent une alternative plus légère à un Worker complet pour proxyfier le chemin Commanders Gateway. Un Snippet exécute du JavaScript à la périphérie et est associé à un **règle de Snippet** qui détermine quelles requêtes l’exécutent.

{% hint style="info" %}
Cloudflare Snippets sont disponibles sur **Pro, Business et Enterprise** forfaits. Le nom d’hôte utilisé pour le gateway doit être proxyfié via Cloudflare.
{% endhint %}

**Étape 1 : Créer le Snippet**

1. Dans le dashboard Cloudflare, ouvrez votre domaine.
2. Allez à **Rules** → **Snippets**.
3. Créez un nouveau Snippet et donnez-lui un nom descriptif, par exemple `Commanders Gateway`.
4. Collez le code suivant :

```javascript
const CONFIG = {
  prefix: "/mypath", // Remplacez par le chemin du gateway choisi pour votre site
  targetBase: "https://s1234.commander4.com", // Remplacez 1234 par l'ID de votre espace de travail/site
  blacklistedCookies: [
    "PHPSESSID",
    "JSESSIONID"
  ]
};

function filterCookieHeader(cookieHeader, blacklist) {
  if (!cookieHeader) return "";
  const blacklistSet = new Set(blacklist);
  return cookieHeader
    .split(";")
    .map(c => c.trim())
    .filter(c => {
      const name = c.split("=")[0].trim();
      return !blacklistSet.has(name);
    })
    .join("; ");
}

export default {
  async fetch(request) {
    const url = new URL(request.url);

    if (!url.pathname.startsWith(CONFIG.prefix)) {
      return new Response("Not Found", { status: 404 });
    }

    const remainingPath = url.pathname.slice(CONFIG.prefix.length) || "/";
    const targetUrl = `${CONFIG.targetBase}${CONFIG.prefix}${remainingPath}${url.search}`;

    const newHeaders = new Headers(request.headers);

    newHeaders.set("X-Forwarded-Host", url.host);
    newHeaders.set("X-Forwarded-Proto", "https");

    const country = request.cf?.country || "";
    const region = request.cf?.region || "";
    if (country) newHeaders.set("X-Forwarded-Country", country);
    if (region) newHeaders.set("X-Forwarded-Region", region);
    if (country && region) {
      newHeaders.set("X-Forwarded-CountryRegion", `${country}-${region}`);
    }

    const cookieHeader = newHeaders.get("Cookie");
    const filteredCookies = filterCookieHeader(cookieHeader, CONFIG.blacklistedCookies);
    if (filteredCookies) {
      newHeaders.set("Cookie", filteredCookies);
    } else {
      newHeaders.delete("Cookie");
    }

    newHeaders.delete("host");

    const proxyRequest = new Request(targetUrl, {
      method: request.method,
      headers: newHeaders,
      body: request.body,
      redirect: "manual"
    });

    const response = await fetch(proxyRequest);

    if (response.status >= 300 && response.status < 400) {
      return new Response(response.body, {
        status: response.status,
        headers: response.headers
      });
    }

    return response;
  }
};
```

**Étape 2 : Personnaliser la configuration**

Mettez à jour les valeurs en haut du Snippet :

* `prefix` : remplacez `/mypath` par le chemin réservé à Commanders Gateway sur votre domaine.
* `targetBase` : remplacez `s1234.commander4.com` par le point de terminaison Commanders Gateway associé à votre ID d’espace de travail/site.
* `blacklistedCookies` : ajoutez tout cookie de session, sensible ou interne qui ne doit pas être transmis à Commanders Gateway.

Le Snippet transmet également le pays et la région du visiteur via `X-Forwarded-Country`, `X-Forwarded-Region`et `X-Forwarded-CountryRegion`.

Les réponses de redirection de Commanders Gateway sont volontairement renvoyées au navigateur au lieu d’être suivies automatiquement à la périphérie.

**Étape 3 : Configurer la règle du Snippet**

Associez le Snippet à une règle qui ne correspond qu’au chemin de votre Commanders Gateway.

Par exemple, dans l’Expression Editor :

```
starts_with(http.request.uri.path, "/mypath")
```

Remplacez `/mypath` par le même chemin configuré dans `CONFIG.prefix`.

{% hint style="warning" %}
Gardez la règle du Snippet et `CONFIG.prefix` synchronisés. S’ils utilisent des chemins différents, les requêtes peuvent ne pas être proxyfiées comme prévu.
{% endhint %}

Déployez le Snippet après l’avoir testé avec les outils de prévisualisation de Cloudflare.

**Étape 4 : Vérifier la configuration**

Après le déploiement, vérifiez :

* `https://example.com/mypath/healthy` → devrait retourner `ok`.
* `https://example.com/mypath/?validate_geo=healthy` → devrait retourner `ok` lorsque le transfert de géolocalisation est correctement configuré.
* Les cookies listés dans `blacklistedCookies` ne sont plus présents dans les requêtes reçues par Commanders Gateway, tandis que les autres cookies sont conservés.
  {% endtab %}

{% tab title="Cloudflare Free" %}
Lors de l’utilisation de Cloudflare Free, la configuration repose sur un **Worker simple** qui proxyfie tout le trafic provenant du chemin choisi (par ex. `/mypath`) vers l’infrastructure Commanders Gateway.

**Étape 1 : Créer le Worker**

1. Dans le Dashboard Cloudflare, allez à **Workers & Pages** → **Créer une application** → **Worker**.
2. Copiez/collez le code suivant :

```javascript
const prefix = "/mypath"; // Chemin d’exemple, remplacez-le par le chemin choisi à l’étape précédente
const sid = "12345"; // ID d’espace de travail d’exemple (alias site ID), remplacez-le par votre propre ID

// Liste des noms de cookie qui ne doivent PAS être transmis à Commanders Gateway. Vous pouvez ajouter vos cookie techniques si nécessaire
const blacklistedCookies = [
  "PHPSESSID",
  "JSESSIONID"
];

addEventListener("fetch", event => {
  event.respondWith(handleRequest(event.request));
});

function filterCookieHeader(cookieHeader, blacklist) {
  if (!cookieHeader) return "";

  const blacklistSet = new Set(blacklist);

  const filteredCookies = cookieHeader
    .split(";")
    .map(cookie => cookie.trim())
    .filter(cookie => {
      const cookieName = cookie.split("=")[0];
      return !blacklistSet.has(cookieName);
    });

  return filteredCookies.join("; ");
}

async function handleRequest(request) {
  const url = new URL(request.url);
  if (url.pathname.startsWith(prefix)) {
    // Construire l’URL cible (elle remplace ${sid} par votre ID d’espace de travail/site ci-dessus)
    const targetUrl = `https://s${sid}.commander4.com${url.pathname}${url.search}`;

    // Cloner les en-têtes de la requête
    const newHeaders = new Headers(request.headers);
    newHeaders.set("X-Forwarded-Host", url.host);

    const country = request.cf?.country || "";
    const region = request.cf?.region || "";
    if (country) newHeaders.set("X-Forwarded-Country", country);
    if (region) newHeaders.set("X-Forwarded-Region", region);
    if (country && region) {
      newHeaders.set("X-Forwarded-CountryRegion", `${country}-${region}`);
    }

    // Filtrer l’en-tête Cookie avant de proxyer la requête.
    const cookieHeader = newHeaders.get("Cookie");
    const filteredCookies = filterCookieHeader(cookieHeader, blacklistedCookies);

    if (filteredCookies) {
      newHeaders.set("Cookie", filteredCookies);
    } else {
      newHeaders.delete("Cookie");
    }

    // Supprimer l’en-tête Host pour éviter les conflits
    newHeaders.delete("host");

    // Proxyer la requête vers l’infrastructure Commanders Gateway
    const proxyRequest = new Request(targetUrl, {
      method: request.method,
      headers: newHeaders,
      body: request.body,
      redirect: "follow"
    });
    return fetch(proxyRequest);
  }
  return new Response("Not Found", { status: 404 }); // Retourner 404 si le chemin de la requête ne correspond pas au préfixe
}
```

Ce Worker proxyfie les requêtes tout en ajoutant des en-têtes supplémentaires (`X-Forwarded-Host`, `X-Forwarded-Country`, `X-Forwarded-Region`).

**Étape 2 : Associer le Worker au chemin**

1. Dans Cloudflare, ouvrez les paramètres de votre domaine.
2. Accédez à **Workers Routes**.
3. Ajoutez une nouvelle route avec :
   * **Motif d’URL**: `www.example.com/mypath*`
   * **Worker**: sélectionnez le Worker créé à l’étape 1.

Une fois enregistré, toutes les requêtes vers `/mypath` seront proxyées vers Commanders Gateway.
{% endtab %}

{% tab title="Akamai" %}
{% hint style="warning" %}
Commanders Gateway avec Akamai est en **bêta**. Si vous avez une question ou un problème avec votre configuration, contactez le support
{% endhint %}

**Créer la règle de redirection**

1. Créez une nouvelle version de votre configuration de diffusion dans **Property Manager**.
2. Dans la section **Property Configuration Settings** ajoutez une nouvelle Rule :
   * Nommez-la : *Route measurement*
3. Ajoutez un nouveau **Match**:
   * Type de correspondance : `Path`
   * Condition : *est l’un de*
   * Valeur : `/mypath/*`
4. Ajoutez un nouveau **Comportement**:
   * Sélectionnez *Standard Property Behavior* et choisissez **Origin Server** comportement.
   * Définir **Origin Server Hostname** à `s1234.commander4.com.`
   * Définir **Forward Host Header** à *Origin Hostname*.
5. Enregistrez la nouvelle règle et déployez vos modifications.
   * ⚠️ Testez la règle de redirection dans votre **environnement de préproduction** avant de la déployer en production.
   * Assurez-vous qu’aucune autre règle ne modifie/supprime les en-têtes de réponse sortants (par ex., *Content-Type*) car cela peut casser des scripts.

***

**Inclure les informations de géolocalisation**

1. Accédez à la section **Property Variables** et ajoutez les variables suivantes :

| Nom de la variable | Paramètres de sécurité |
| ------------------ | ---------------------- |
| USER\_REGION       | Hidden                 |
| USER\_COUNTRY      | Hidden                 |

2. Choisissez votre **Redirect rule** (créée ci-dessus) dans Property Configuration Settings.
3. Ajoutez deux nouveaux **Set Variable** comportements (un par variable) :

| Variable              | Create Value From | Get Data From  | Edgescape Field | Operation |
| --------------------- | ----------------- | -------------- | --------------- | --------- |
| PMUSER\_USER\_REGION  | Extract           | Edgescape Data | Region Code     | None      |
| PMUSER\_USER\_COUNTRY | Extract           | Edgescape Data | Country Code    | None      |

4. Ajoutez deux nouveaux **Modify Outgoing Request Header** comportements :

| Action | Select Header Name | Custom Header Name  | Header Value                   |
| ------ | ------------------ | ------------------- | ------------------------------ |
| Add    | Other...           | X-Forwarded-Region  | {{user.PMUSER\_USER\_REGION}}  |
| Add    | Other...           | X-Forwarded-Country | {{user.PMUSER\_USER\_COUNTRY}} |

5. Enregistrez la nouvelle règle et déployez vos modifications.

***

**Filtrer les cookies avant de les transmettre à Commanders Gateway**

Vous pouvez empêcher des cookies spécifiques d’être transmis à Commanders Gateway. Cela peut être utile pour les cookies de session, les cookies contenant des informations sensibles ou les cookies techniques internes qui ne doivent pas quitter votre infrastructure.

La liste des cookies à exclure dépend des exigences de votre organisation.

**Option 1 : utiliser les capacités de gestion des cookies d’Akamai**

Si des comportements de gestion des cookies sont disponibles avec votre configuration Akamai, configurez Akamai pour supprimer les cookies concernés de la requête avant qu’elle ne soit transmise à Commanders Gateway.

Par exemple, vous pouvez vouloir exclure des cookies tels que :

```
PHPSESSID
JSESSIONID
```

Configurez le comportement de sorte que ces cookies soient supprimés de la **requête client envoyée à l’origine**, où l’origine est votre point de terminaison Commanders Gateway.

{% hint style="info" %}
Le nom exact et la disponibilité des comportements de gestion des cookies Akamai peuvent varier selon les produits Akamai activés sur votre compte.
{% endhint %}

**Option 2 : modifier l’en-tête Cookie sortant**

Si les capacités de gestion des cookies ne sont pas disponibles, vous pouvez utiliser un **Modify Outgoing Request Header** comportement sur l’en-tête `Cookie` et supprimer les cookies sélectionnés à l’aide d’une expression régulière.

Exemple pour `PHPSESSID` et `JSESSIONID`:

```regex
(?:^|;\s*)(PHPSESSID|JSESSIONID)=[^;]*
```

Configurez :

* **En-tête :** `Cookie`
* **Action :** Remplacement par regex
* **Expression régulière :** l’expression ci-dessus, adaptée à votre liste de cookies
* **Remplacement :** vide

{% hint style="warning" %}
Testez soigneusement cette configuration avant de la déployer en production. Une expression régulière incorrecte peut entraîner un `Cookie` en-tête mal formé ou supprimer involontairement des cookies qui devraient être transmis.
{% endhint %}

Si vous utilisez plusieurs configurations CDN ou de périphérie pour la même implémentation, gardez la liste d’exclusion des cookies cohérente entre elles.

***

**Vérifier la configuration**

Après le déploiement de la configuration Akamai :

* Accédez à `https://example.com/mypath/healthy` → devrait afficher `ok`.
* Tester les en-têtes de géolocalisation : `https://example.com/mypath/?validate_geo=healthy` → devrait aussi afficher `ok`.
* Vérifiez que les requêtes transmises à Commanders Gateway ne contiennent plus les noms de cookies exclus, tandis que les autres cookies sont toujours transmis normalement.
  {% endtab %}

{% tab title="Fastly" %}
{% hint style="warning" %}
Le support Fastly pour Commanders Gateway est actuellement en **bêta**. Les étapes ci-dessous sont destinées aux utilisateurs techniques familiers avec Fastly Compute (Compute Services). Selon la configuration de votre compte Fastly (domaines, TLS, produits activés), certaines étapes de liaison en production peuvent varier.
{% endhint %}

Lors de l’utilisation de Fastly, la configuration est différente de Cloudflare. Vous déployez un **service Compute** (Wasm) et le configurez principalement via le **Fastly API et CLI** depuis un terminal.

**Prérequis**

1. Créez un jeton API dans l’interface Fastly (les scopes doivent autoriser Compute, services, backends et déploiements).
2. Exportez le jeton dans votre environnement de terminal :

```
export FASTLY_API_TOKEN=XXXXXXXXXXXX
```

3. Installez les prérequis :

* Node.js
* Fastly CLI

**Étape 1 : Créer le service Compute**

Créez un nouveau service Compute :

```
fastly service create --name "CA Gateway" --type wasm
```

Fastly renvoie un **ID de service**, par exemple :

```
dyBxiT8wpc2c8ZQg2KRrMN
```

Enregistrez-le, vous en aurez besoin pour la création du backend et les déploiements.

**Étape 2 : Créer un projet Compute local (starter kit)**

Générez un projet local à partir du starter kit JavaScript par défaut :

```
npm create @fastly/compute@latest -- --language=javascript --default-starter-kit
```

Cela crée une structure de projet similaire à :

```
.
├── README.md
├── fastly.toml
├── package.json
└── src
    ├── index.js
    └── welcome-to-compute.html
```

**Étape 3 : Configurer l’ID de service dans fastly.toml**

Modifiez `fastly.toml` et définissez l’ID de service :

```
# fastly.toml
service_id = "YOUR_SERVICE_ID"
```

**Étape 4 : Créer le backend (origine Commanders Gateway)**

Créez un backend qui pointe vers l’infrastructure Commanders Gateway (remplacez `1234` par votre ID d’espace de travail/site) :

```
fastly backend create \\
  --service-id YOUR_SERVICE_ID \\
  --version 1 \\
  --name commander_gateway \\
  --address s1234.commander4.com \\
  --use-ssl \\
  --port 443 \\
  --ssl-sni-hostname s1234.commander4.com
```

Notes :

* `--version 1` est un point de départ typique. Si votre service a déjà des versions, utilisez la version que vous souhaitez déployer.
* Le backend doit être `s1234.commander4.com` (votre propre ID d’espace de travail/site).

**Étape 5 : Implémenter la logique de routage dans src/index.js**

Remplacez le contenu de `src/index.js` par le code Worker suivant.

Vous devez mettre à jour :

* `prefix` (votre chemin client, exemple : `/mypath`)
* `sid` (votre ID d’espace de travail/site Commanders, exemple : `s1234`)

```javascript
/// <reference types="@fastly/js-compute" />

import { env } from "fastly:env";
import { includeBytes } from "fastly:experimental";

const prefix = "/PATHACHANGER";              // TODO : remplacez par le chemin gateway choisi (par ex. "/mypath")
const sid = "s123456";                       // TODO : remplacez par votre ID d’espace de travail/site (par ex. "s1234")
const BACKEND = "commander_gateway";         // Nom du backend Fastly pointant vers sid.commander4.com

const STRIP_PREFIX = true;                   // Si vrai, supprime le prefix du chemin transmis
const PREPEND_PATH = "/gateway";             // Point d’entrée interne du gateway côté Commanders (ne pas modifier)

// Liste des noms de cookies qui ne doivent PAS être transmis à Commanders Gateway. Ajoutez vos cookies techniques si nécessaire
const blacklistedCookies = [
  "PHPSESSID",
  "JSESSIONID"
];

addEventListener("fetch", (event) => event.respondWith(handleRequest(event.request)));

function filterCookieHeader(cookieHeader, blacklist) {
  if (!cookieHeader) return "";

  const blacklistSet = new Set(blacklist);

  const filteredCookies = cookieHeader
    .split(";")
    .map(cookie => cookie.trim())
    .filter(cookie => {
      const cookieName = cookie.split("=")[0];
      return !blacklistSet.has(cookieName);
    });

  return filteredCookies.join("; ");
}

async function handleRequest(request) {

  const url = new URL(request.url);

  // Proxyfier uniquement les requêtes qui correspondent au prefix configuré
  if (!url.pathname.startsWith(prefix)) {
    return new Response("Not Found", { status: 404 });
  }

  // Construire le chemin qui sera transmis à Commanders Gateway
  let fwdPath = url.pathname;

  // Supprimer éventuellement le prefix client (par ex. "/mypath") pour que l’origine reçoive "/"
  if (STRIP_PREFIX) {
    fwdPath = fwdPath.slice(prefix.length) || "/";
  }

  // Ajouter le point d’entrée interne Commanders (obligatoire)
  if (PREPEND_PATH) {
    fwdPath = PREPEND_PATH + fwdPath;
  }

  // URL d’origine finale sur l’infrastructure Commanders
  const target = `https://${sid}.commander4.com${fwdPath}${url.search}`;

  // Cloner les en-têtes et ajouter les informations de transfert
  const headers = new Headers(request.headers);
  headers.set("X-Forwarded-Host", url.host);

  // Transmettre les informations géographiques lorsqu’elles sont disponibles (facultatif mais recommandé)
  const country = (request.geo && request.geo.country_code) ? request.geo.country_code.toUpperCase() : "";
  const region  = (request.geo && request.geo.region) ? request.geo.region : "";
  if (country) headers.set("X-Forwarded-Country", country);
  if (region)  headers.set("X-Forwarded-Region", region);
  if (country && region) headers.set("X-Forwarded-CountryRegion", `${country}-${region}`);

  // Filtrer l’en-tête Cookie avant de proxyer la requête.
  const cookieHeader = headers.get("Cookie");
  const filteredCookies = filterCookieHeader(cookieHeader, blacklistedCookies);

  if (filteredCookies) {
    headers.set("Cookie", filteredCookies);
  } else {
    headers.delete("Cookie"); // Supprimer complètement l’en-tête Cookie si tous les cookies ont été filtrés
  }

  // Éviter les conflits de l’en-tête Host à l’origine
  headers.delete("host");

  // Reconstruire la requête pour l’origine
  const originReq = new Request(target, {
    method: request.method,
    headers,
    body: request.body
  });

  // Contourner le cache pour garantir que les hits de mesure ne soient jamais mis en cache
  const co = new CacheOverride("pass");

  // Envoyer la requête au backend Fastly configuré
  return fetch(originReq, { backend: BACKEND, cacheOverride: co });

}
```

Important :

* Remplacez `s1234.commander4.com` avec le véritable point de terminaison de votre ID d’espace de travail/site.
* Conservez la même valeur `prefix` que le chemin que vous réservez sur le domaine client (exemple : `/mypath`).
* N’ajoutez PAS de slash final à la fin du chemin dans les URL côté client.

**Étape 6 : Déploiement**

Déployez le service Compute :

```
npm run deploy
```

**Étape 7 : Test**

Après le déploiement, Fastly fournit un domaine temporaire pour les tests, par exemple :

```
https://plainly-rested-bison.edgecompute.app/mypath/healthy
```

Il devrait renvoyer :

```
ok
```

**Liaison de production (domaine client)**

À ce stade, le service Compute s’exécute sur un domaine de test fourni par Fastly. Pour passer en production sur le domaine client (exemple : `https://example.com/mypath/`), vous devez encore lier le service au domaine de production et vous assurer que TLS est en place.

Cela implique généralement, selon la configuration du client :

* Ajouter le domaine client au service Fastly et configurer TLS pour celui-ci (TLS géré ou certificat client).
* Créer l’enregistrement DNS requis (souvent un CNAME) pour que `example.com` pointe vers Fastly.
* S’assurer que le service Compute est celui qui reçoit les requêtes pour le chemin choisi (exemple : `/mypath*`) sur ce domaine.

Comme les étapes exactes dépendent des produits Fastly activés sur le compte et de la manière dont le client gère TLS et DNS, considérez ceci comme une étape bêta et contactez le support si vous avez besoin des commandes exactes pour votre configuration spécifique.
{% endtab %}
{% endtabs %}

***

## Étape 3 : Mettez à jour les scripts dans votre système de tag management ou votre site web

Remplacez les URL des scripts du fournisseur par les nouveaux **chemins First-party**.

Exemples :

### Google

```html
<!-- Au lieu de -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-12345"></script>

<!-- Utilisez -->
<script async src="/mypath/"></script>
```

### Meta (Facebook Pixel)

```html
<!-- Au lieu de -->
<script src="https://connect.facebook.net/en_US/fbevents.js"></script>

<!-- Utilisez (chemin obfusqué fourni dans l’interface Commanders Act) -->
<script src="/mypath/js/f4558899203.js"></script>
```

### Snapchat

```html
<script src="/mypath/js/a82b99df732.js"></script>
```

### Bing (UET)

```html
<script src="/mypath/js/c77ac91be11.js"></script>
```

Chaque nom de fichier obfusqué est généré automatiquement et disponible dans le **interface Commanders Act First-Party Hosting**.

### OneTag

Vous pouvez modifier manuellement le domaine de votre configuration cact() avec la `collectionDomain` propriété. Exemple :

```javascript
cact(..., {collectionDomain: "www.youdomain.com/mypath"});
```

Avertissement : n’ajoutez PAS un `/` à la fin du chemin

***

## Étape 4 : Vérifiez la configuration

* Pour le chemin global, vérifiez le point de terminaison de santé :
  * `https://example.com/mypath/healthy` → devrait retourner `ok`
* Utilisez les outils de développement du navigateur pour vérifier que :
  * Les scripts Google sont chargés depuis `/mypath/`
  * Les scripts des autres fournisseurs sont chargés depuis `/mypath/js/{obfuscated}.js`
  * Les requêtes sont envoyées à votre **domaine first-party**.
* Assurez-vous que les événements apparaissent dans les dashboards des partenaires concernés (Google Analytics, Facebook Events Manager, etc.).

***

## Avantages

* **Durabilité**: Le tracking continue de fonctionner même avec Safari ITP et les restrictions liées aux Third-party cookie.
* **Résilience**: Servir les scripts depuis votre domaine avec des noms de fichiers obfusqués rend plus difficile l’interférence des règles de blocage.
* **Configuration centralisée**: Un seul chemin (`/mypath`) gère tous les fournisseurs.
* **Pérenne**: S’adapte à Privacy Sandbox et aux futures restrictions des navigateurs.
*

## Configurez la collecte de données First party pour les fonctionnalités Commanders Act (via Gateway)

Ce chapitre explique comment acheminer la collecte de données Commanders Act via votre **chemin gateway First party** (par exemple `/mypath`) pour les principales fonctionnalités Commanders Act.

Notes importantes :

* Le chemin de gateway affiché dans les exemples (`/mypath`) n’est qu’un exemple. Les clients choisissent leur propre chemin lors de la configuration du gateway dans leur outil CDN ou edge (Cloudflare, Akamai, etc.).
* Tous les exemples ci-dessous supposent que votre gateway est en bon état : `https://example.com/mypath/healthy` renvoie `ok`.

***

### 1. Destinations server-side via le gateway (exemple : Meta Facebook CAPI)

Le tracking server-side Commanders Act repose sur **oneTag** tags. En général, vous aurez un oneTag par événement que vous souhaitez collecter, par exemple :

* `page_view`
* `add_to_cart`
* `purchase`

Pour acheminer ces événements oneTag via le gateway, vous devez mettre à jour la **configuration du tag oneTag** afin que la `cact()` configuration utilise votre domaine de collecte First party et votre chemin.

Dans votre tag oneTag (ou dans le snippet partagé utilisé par vos tags oneTag), définissez `collectionDomain`:

```javascript
cact(..., { collectionDomain: "www.yourdomain.com/mypath" });
```

Notes :

* Remplacez `www.yourdomain.com/mypath` avec votre propre domaine et le chemin que vous avez configuré dans votre gateway.
* N’ajoutez PAS de `/` à la fin du chemin.
* Une fois cela configuré, tous les événements oneTag (page\_view, add\_to\_cart, purchase, etc.) seront collectés via votre chemin de gateway First party.

***

### 2. Collecte CDP, Campaign Analytics et CMP via le gateway

*(Data Activation, Campaign Analytics, statistiques CMP et preuve de consentement)*

Ces trois fonctionnalités reposent sur le même mécanisme de routage. Pour envoyer leurs données via le gateway, vous devez définir la variable **`tC.clientCollectDns`** soit :

* directement dans chaque tag concerné, **ou**
* dans un **tag de configuration global** qui s’exécute avant tous les tags Commanders Act (recommandé).

Exemple :

```javascript
tC.clientCollectDns = "www.yourdomain.com/mypath";
```

Comportement :

* Dès que `tC.clientCollectDns` est défini, la collecte pour **Data Activation, Campaign Analytics et le tracking lié au CMP** se fera via le gateway.
* `mypath` n’est qu’un exemple. Les clients peuvent utiliser n’importe quel chemin qu’ils ont configuré dans leur configuration du gateway.

Options d’implémentation :

* **Option A (simple) :** ajoutez la ligne directement dans le tag Data Activation / Campaign Analytics / CMP.
* **Option B (recommandé) :** ajoutez-la dans un tag de configuration global qui s’exécute avant tous les tags Commanders Act.

***

### Liste de vérification

Après avoir appliqué les changements ci-dessus, vérifiez :

* Le point de terminaison de santé du gateway : `https://example.com/mypath/healthy` renvoie `ok`.
* Dans les DevTools du navigateur (onglet Network), les requêtes de collecte Commanders Act vont vers votre domaine et votre chemin First party (par exemple `https://example.com/mypath/...`).
* Les événements et les données apparaissent comme prévu dans :
  * les dashboards de destinations server-side (exemple : Meta Events Manager pour CAPI)
  * les flows Data Activation
  * les rapports de statistiques CMP et de preuve de consentement (le cas échéant)
  * les rapports Campaign Analytics


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://doc.commandersact.com/fr/developpeurs/commanders-tag-gateway.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.