Dans la publicité digitale, chaque impression diffusée déclenche un log qui traverse tout un pipeline de données avant d’atterrir dans les tables de reporting et de facturation.
Un log perdu, dédoublé ou mal transformé en cours de route, c’est potentiellement de l’argent facturé à tort, ou pas facturé du tout. Et ces régressions sont particulièrement difficiles à détecter : l’API répond 200, l’interface affiche la pub, tout semble fonctionner. Pourtant, plus loin dans la chaîne, la donnée peut déjà être corrompue.
L’objectif du projet : automatiser la vérification de ce trajet complet, en continu, pour détecter les anomalies avant qu’elles n’atteignent les clients.
Le parcours reproduit par chaque test :
- Générer un jeton unique au run, le fil rouge qui permettra de retrouver cette exécution précise parmi des milliards de lignes.
- L’injecter comme mot-clé de ciblage dans un appel publicitaire, vers des campagnes de test permanentes et déjà en ligne.
- Déclencher le pixel de tracking de l’impression servie.
- Vérifier que l’événement arrive bien en base « staging » du data warehouse, retrouvé par ce jeton.
- Déposer dans une file d’attente ce qu’on s’attend à voir compté plus loin, avec une échéance.
La suite ne se passe plus dans le test. Une impression met de quinze minutes à plusieurs heures à être agrégée dans les tables de reporting : plutôt que de faire dormir un test pendant tout ce temps, un réconciliateur tourne en continu, reprend les lignes arrivées à échéance et tranche, compté, compté en retard, ou jamais compté. Le test dépose une promesse, un autre processus vérifie qu’elle a été tenue. C’est le changement d’architecture qui a le plus payé.
Côté stack : Playwright orchestre les appels et le suivi du log, BigQuery sert à la fois d’oracle, on y lit la donnée transformée pour la confronter au résultat attendu et de mémoire, chaque exécution laissant une trace durable.
Le piège qu’on n’avait pas anticipé : il n’existe pas de clé de corrélation universelle. Le mot-clé traverse très bien le chemin classique, mais il n’est jamais loggué sur le chemin server-side, il faut alors s’appuyer sur l’identifiant d’opportunité publié par la réponse d’enchère, ou sur un identifiant de créa qu’on écrit soi-même dans une réponse de DSP forgée. Un oracle par surface, vérifié des deux côtés avant d’être câblé.
Dernière leçon, moins technique : une suite qui surveille un environnement partagé passe son temps à distinguer un vrai bug d’un incident d’environnement. Chaque échec est donc classé par ce qu’il accuse (le pipeline, l’environnement, ou la diffusion) et seul le premier rend le rapport rouge. Sans ça, soixante-dix secondes d’indisponibilité d’une API de setup suffisent à tout repeindre en rouge, et plus personne ne lit le rapport.
Un point souvent sous-estimé : ce type de validation n’est possible que dans un véritable environnement de test end-to-end, où tous les maillons du pipeline sont présents et reliés comme en production. Tester chaque brique isolément ne suffit pas, la plupart des bugs de data vivent précisément entre les briques. Investir dans cet environnement, c’est ce qui permet de détecter les régressions data de façon proactive, avant qu’un client ne le fasse à notre place.