Réalisations

Le point de départ.

La collecte des événements de navigation reposait sur du tag management côté client. Entre les ad-blockers, les restrictions d'Apple (ITP) et le poids du JavaScript tiers sur les performances des pages, une part croissante du signal se perdait avant même d'atteindre les outils d'analytics. Dans le même temps, la facture cloud du dispositif montait avec le trafic.

La demande initiale portait sur la perte de signal. Le diagnostic a révélé deux problèmes distincts : le signal, effectivement, et un coût d'infrastructure dont la cause n'était pas celle qu'on croyait.

Ce que nous avons construit.

Un pipeline de collecte first-party, en architecture de streaming temps réel : un point de collecte sous les domaines du client, Kafka comme colonne vertébrale, et un fan-out vers les consommateurs : analytics, personnalisation, A/B testing, datalake.

Trois choix structurants, portés en équipe. Un schéma d'événements versionné qui sert de contrat entre producteurs et consommateurs : un événement invalide est rejeté à l'entrée, pas découvert trois systèmes plus loin. Des garanties de livraison at-least-once, avec déduplication idempotente, retries à backoff exponentiel et files de rejeu (DLQ) pour ne rien perdre quand une destination tombe. Et le consentement traité comme une donnée de premier ordre : l'état CMP voyage avec chaque événement et conditionne son routage.

En production : de l'ordre de 300 millions d'événements par jour, avec des pointes à 6 000 événements par seconde.

D'où viennent les −70 %.

La facture ne venait pas d'un poste unique. L'analyse de la consommation, ligne à ligne, a mis au jour l'accumulation classique d'un système qui a grandi vite : un logging trop volumineux, des payloads verbeux et non compressés, du cache absent là où il aurait compté, des fuites mémoire dans certains services. Nous avons corrigé poste par poste, avant de toucher à la plateforme.

Restait le modèle d'exécution. Cloud Run est simple et pertinent à faible volume, mais sa facturation à la requête devient structurellement défavorable face à une charge soutenue de plusieurs milliers d'événements par seconde. La migration vers GKE (bin-packing, autoscaling, right-sizing des ressources) a aligné le coût sur la charge réelle.

Les deux effets combinés : −70 % sur la facture d'infrastructure du périmètre.

Ce que le système est devenu.

Le pipeline est toujours en production. Le signe qui compte : ajouter un nouveau type d'événement est devenu une opération de configuration, couverte par des tests de non-régression automatisés, et non plus un chantier de développement. C'est à cela qu'on reconnaît une fondation durable.