Le vendredi 27 novembre 2026, votre serveur sGTM ne tombera probablement pas. Vraiment. La panne d’infrastructure est le risque le moins probable de votre Black Friday. Ce qui casse le jour du pic, c’est autre chose : la facture Cloud Run qui triple sans prévenir, l’export GA4 vers BigQuery qui se suspend en dépassant le million d’événements, les rapports qui basculent en (other) au moment précis où le CEO regarde le dashboard, et le fait que Google gèle les déploiements pendant tout le week-end. Ce guide est une checklist datée pour préparer votre tracking Black Friday sans mauvaise surprise, à exécuter entre maintenant et le 18 novembre.
Autant le dire tout de suite : cet article ne vend pas la peur. La plupart des setups server-side tiennent le pic sans broncher. Le vrai danger n’est pas la disponibilité, il est budgétaire et analytique. Et c’est justement ce que la documentation officielle de Google sur les pics de trafic ne dit pas : elle recommande de « réserver de la capacité » et de « vérifier ses quotas », sans donner un seul chiffre, et elle n’a pas été mise à jour depuis le 9 octobre 2024. On va donner les chiffres, l’ordre des opérations, et surtout les trois choses qu’elle ne mentionne jamais.
Ce qui casse vraiment le jour du Black Friday
Avant de toucher à quoi que ce soit, remettons les risques dans l’ordre. Sur un setup sGTM correctement dimensionné, la disponibilité du serveur est rarement le problème : Cloud Run scale horizontalement, et un tag manager server-side est une charge légère et prévisible. Ce qui fait mal, ce sont trois choses beaucoup plus discrètes.
Le premier risque est le coût. Votre facture suit votre trafic, et un trafic multiplié par cinq un vendredi, c’est une facture multipliée par cinq ce jour-là. Personne ne s’en rend compte avant de recevoir la note en décembre.
Le deuxième est la perte de données. Certains seuils GA4 et BigQuery se déclenchent au volume, et le jour du pic est précisément celui où vous les franchissez pour la première fois. Vous perdez les données du jour le plus important de l’année.
Le troisième est l’illisibilité des rapports. La cardinalité explose, item_name et page_location partent dans (other), et vos rapports e-commerce deviennent inexploitables au moment où tout le monde veut les regarder.
Panne serveur : peu probable. Coût, perte de données, rapports illisibles : voilà où passer votre temps de préparation. On traite chaque bloc dans l’ordre.
Bloc 1, l’infra sGTM : calculer avant de régler
Si vous n’êtes pas encore passé au server-side, cet article n’est pas le bon point de départ : commencez par le guide pour migrer vers le GTM server-side, puis revenez ici. Pour les autres, la règle de ce bloc tient en une phrase : on calcule d’abord, on règle ensuite. Provisionner au hasard, c’est soit payer pour du vide, soit se faire déborder.
Calculer votre volume projeté au pic
La question à laquelle vous devez répondre n’est pas « combien d’instances ? » mais « combien de requêtes par seconde au pic ? ». La méthode est simple. Prenez votre pic de requêtes/seconde d’un jour normal (visible dans les métriques Cloud Run), appliquez votre multiplicateur Black Friday attendu (regardez l’an dernier, souvent entre trois et six), puis divisez par la capacité observée d’une instance.
Un exemple, présenté comme un exemple et pas comme une vérité universelle : si une instance encaisse tranquillement 50 requêtes/seconde chez vous, et que vous projetez 600 requêtes/seconde au pic, il vous faut de l’ordre de 12 instances actives simultanément, avec de la marge par-dessus. Le chiffre exact dépend de vos containers, de vos tags sortants et de votre région. Ne recopiez pas le 12, refaites le calcul avec vos propres métriques.
Régler min instances et max instances
La documentation Google est claire sur le principe, moins sur les chiffres. Le min instances doit être réglé pour absorber le trafic sans laisser Cloud Run démarrer des instances à froid en plein pic (le cold start ajoute de la latence pile au mauvais moment). En pratique, montez le min instances au niveau de votre creux projeté du week-end, au minimum, et rapprochez-le du pic si votre budget le permet pour éviter tout démarrage à froid pendant la campagne.
Le max instances, lui, est votre garde-fou. Réglez-le au-dessus de votre pic calculé, avec de la marge, mais pas à l’infini : c’est aussi votre plafond de coût en cas d’anomalie ou d’attaque. Un max instances laissé par défaut est une facture non plafonnée.
1 vCPU par instance, et pourquoi en ajouter casse l’autoscaling
Piège classique et contre-intuitif : garder 1 vCPU par instance. Ajouter des vCPU pour « encaisser plus » est souvent une erreur en server-side, parce que l’autoscaling de Cloud Run se déclenche sur l’usage CPU. Des instances plus grosses restent sous-utilisées plus longtemps, l’autoscaler tarde à ajouter des instances, et vous vous retrouvez avec moins de parallélisme au pic. On veut beaucoup de petites instances à 1 vCPU, pas quelques grosses. Activez aussi le CPU always allocated pour un service qui reçoit du trafic en continu, afin d’éviter les à-coups.
Vérifier les quotas Cloud Run avant de demander une hausse
Voici l’étape que tout le monde oublie et qui se paie cash : vos quotas régionaux Cloud Run (nombre max d’instances par région, notamment) peuvent plafonner en dessous de ce que votre max instances réclame. Vérifiez-les maintenant, dans la console GCP. Si une augmentation de quota est nécessaire, elle passe par un ticket Google qui n’est pas instantané, et surtout : elle ne se traitera pas pendant la fenêtre de gel de fin novembre. Une demande de quota déposée le 24 novembre, c’est une demande qui n’aboutira pas à temps.
Passer l’image sGTM en dernière version avant le gel
Dernier point de ce bloc : montez votre image Docker sGTM en dernière version stable (la 4.4.0 date du 22 juillet 2026, d’après les release notes du server-side tagging) bien avant la fenêtre de gel. Vous ne voulez pas découvrir un bug de version au pire moment, ni tenter une mise à jour d’image pendant le week-end où Google fige les redémarrages d’infra. Si vous ajoutez beaucoup de CAPI sortantes, gardez en tête qu’elles multiplient les requêtes serveur au pic : notre article sur la déduplication Meta CAPI et l’Event Match Quality détaille ce que chaque conversion envoie réellement côté serveur.
Bloc 2, le coût : le vrai risque
C’est ici que se joue la vraie mauvaise surprise du Black Friday, et c’est aussi ce dont la doc Google ne parle pas du tout. Votre coût de tracking suit votre trafic, mécaniquement.
Si vous êtes en auto-hébergé sur Cloud Run, la facture grimpe avec le nombre d’instances-secondes consommées. Posez une alerte de budget GCP maintenant, pas en décembre : fixez un seuil mensuel réaliste intégrant le pic, et une alerte à 50 %, 90 % et 100 %. Ça ne plafonne pas la dépense, mais ça vous prévient avant la note.
Si vous êtes chez un hébergeur managé, le piège est différent et plus vicieux : la plupart facturent au palier de requêtes, et un pic vous fait sauter de palier, parfois pour tout le mois. C’est exactement le « piège du décompte en requêtes » que je détaille dans l’article sur combien coûte vraiment le GTM server-side. Vérifiez le comportement précis de votre offre au dépassement : facturation à l’usage, palier bloqué au mois, ou coupure. Le comparatif Stape vs Addingwell reprend la logique de facturation de chaque hébergeur, utile pour anticiper votre facture de novembre.
Enfin, si vous avez un export BigQuery direct depuis sGTM, le pic gonfle aussi votre coût de stockage et de streaming inserts. Ce n’est pas le poste le plus lourd, mais il mérite d’être dans votre alerte de budget.
Bloc 3, les données et les rapports
L’infra tient, la facture est sous surveillance. Reste le risque le plus sournois : perdre ou rendre illisibles les données du jour le plus important de l’année.
L’export GA4 BigQuery et la limite du million
Voici le piège numéro un côté données. Sur une propriété GA4 standard (non 360), l’export BigQuery est plafonné autour d’un million d’événements par jour, et au-delà, l’export du jour peut être suspendu. Devinez quel jour vous franchissez ce seuil pour la première fois ? Le 27 novembre. Vous perdez l’export du jour le plus riche de l’année, sans alerte claire.
Deux parades. Vérifiez dès maintenant votre volume d’événements quotidien : si vous approchez déjà les 800 000 en semaine, le pic vous fera exploser le seuil à coup sûr. Et surtout, envisagez l’export BigQuery direct depuis sGTM, qui contourne la limite du million en écrivant depuis le serveur, indépendamment du connecteur GA4 standard. C’est la parade la plus solide pour un gros pic, mais elle se met en place avant, pas le jour même.
La cardinalité qui pousse vos items dans (other)
Quand le volume explose, la cardinalité de vos dimensions explose avec lui. GA4 a un plafond de valeurs distinctes par dimension et par jour, au-delà duquel il regroupe le surplus dans une ligne (other). Le jour du pic, avec des milliers de item_name, item_id ou page_location différents, vos rapports e-commerce standards peuvent devenir illisibles, tout se retrouvant dans (other). Vérifiez maintenant la propreté de votre implémentation e-commerce : le guide du suivi e-commerce GA4 via GTM revient sur les bonnes pratiques du tableau items et sur la façon de garder une cardinalité maîtrisée. Pour l’analyse fine du pic, prévoyez de passer par BigQuery, qui ne connaît pas cette limite de cardinalité.
Data thresholding et Google Signals
Autre effet de bord : le data thresholding. Quand Google Signals est actif, GA4 masque les lignes de rapport dont l’effectif est trop faible pour préserver l’anonymat. Contre-intuitivement, un très gros volume ne vous protège pas : les segments fins (une combinaison rare d’appareil, de zone et de source) restent masqués. Si vous avez besoin d’une granularité totale sur la période, l’export BigQuery est là encore votre filet de sécurité, car il n’applique pas le thresholding.
Ne touchez pas la fenêtre de conversion en pleine campagne
Règle d’or : on ne modifie pas la fenêtre de conversion pendant la campagne. Changer cette valeur en plein Black Friday rend vos comparaisons ininterprétables et perturbe l’attribution au pire moment. Si vous vous posez la question du bon réglage, tranchez-la maintenant, avant le pic : voir quelle fenêtre de conversion GA4 choisir. Après, on n’y touche plus.
Et pendant qu’on parle de propreté du setup : le meilleur moment pour corriger vos erreurs de configuration, c’est septembre, pas novembre. Passez votre propriété au crible avec l’audit GA4 des erreurs de configuration à corriger tant que vous avez le temps de tester.
La fenêtre de gel Google
Point que presque personne n’anticipe : Google gèle une partie de son écosystème pendant le week-end de Black Friday et Cyber Monday. Concrètement, les changements de code et les redémarrages non essentiels sont mis en pause côté GTM, et Google Cloud met en pause certaines mises à jour d’infrastructure, déploiements et opérations de cycle de vie sur la période. Traduction opérationnelle : le correctif que vous vouliez pousser le vendredi matin risque de ne pas partir, et l’augmentation de quota demandée la veille ne sera pas traitée.
La conséquence est simple et elle change tout votre planning : votre propre gel doit commencer avant celui de Google. Considérez que tout doit être en place, testé et déployé le 18 novembre au soir. À partir de là, vous ne touchez plus à votre infra ni à vos tags critiques, sauf urgence absolue. La fenêtre de préparation recommandée par Google va d’une semaine avant Thanksgiving à deux jours après Cyber Monday, soit du 19 novembre au 2 décembre : c’est votre période de vigilance en lecture seule, pas de chantier.
Le calendrier Black Friday, action par date
Voici la checklist datée. Imprimez-la, cochez-la, partagez-la en équipe.
| Échéance | Action | Bloc |
|---|---|---|
| Cette semaine (8 sept) | Relever le pic req/s actuel et projeter le volume Black Friday | Infra |
| Cette semaine | Poser l’alerte de budget GCP (50 / 90 / 100 %) | Coût |
| Cette semaine | Vérifier le volume d’événements GA4 quotidien vs seuil du million | Données |
| D’ici fin septembre | Lancer l’audit GA4 et corriger les erreurs de config | Données |
| D’ici mi-octobre | Vérifier les quotas Cloud Run et demander une hausse si besoin | Infra |
| D’ici fin octobre | Régler min/max instances, 1 vCPU, CPU always allocated | Infra |
| D’ici début novembre | Mettre en place l’export BigQuery direct si volume à risque | Données |
| D’ici début novembre | Trancher la fenêtre de conversion (et ne plus y toucher) | Données |
| Avant le 15 novembre | Passer l’image sGTM en dernière version stable | Infra |
| 18 novembre au soir | Gel interne : tout est déployé et testé, on fige | Tous |
| 19 nov au 2 déc | Vigilance en lecture seule, aucun changement non urgent | Tous |
| 30 novembre | Post-mortem des données du week-end | Données |
Le lendemain, le 30 novembre
Le week-end est passé. La vraie question du lundi n’est pas « combien on a vendu » (le business le sait déjà) mais « a-t-on bien tout mesuré ? ». Regardez trois choses. D’abord, l’export BigQuery : y a-t-il un trou sur le 27 ou le 28 novembre ? Une table quotidienne manquante ou tronquée signale une suspension d’export. Ensuite, la part de (other) dans vos rapports e-commerce du week-end : si elle a bondi, votre cardinalité a débordé et l’analyse fine passera par BigQuery. Enfin, l’écart entre vos conversions GA4 et vos plateformes publicitaires, pour repérer une perte de signal serveur.
Si quelque chose cloche, ne devinez pas : le diagnostic des données GA4 manquantes donne la marche à suivre pour distinguer un bug Google d’un problème de votre tracking. C’est le bon réflexe avant de conclure que « GA4 a perdu des ventes ».
En résumé
Votre Black Friday tracking ne se joue pas le 27 novembre, il se joue maintenant. La panne serveur est un faux problème ; les vrais sont le coût, la perte de données et les rapports illisibles. Trois gestes valent tous les autres si vous ne deviez en retenir que trois : posez votre alerte de budget cette semaine, vérifiez votre volume d’événements contre le seuil du million avant qu’il ne soit trop tard, et bouclez tout votre déploiement le 18 novembre parce que Google gèlera avant vous. Le reste, c’est du calcul et de la discipline de calendrier. Et si vous préférez déléguer l’audit pré-pic, c’est exactement le genre de mission qui se prépare en septembre, pas la veille.