Analytics temps réel avec ClickHouse

Une plateforme SaaS de marketing et de fidélité pour centres commerciaux, utilisée par de grands groupes retail en Europe. Chaque client consulte quotidiennement ses dashboards : participation aux campagnes, transactions, engagement des visiteurs.

Le volume de données avait grandi plus vite que l'architecture. Les agrégations tournaient directement sur la base opérationnelle MongoDB, pensée pour le transactionnel, pas pour l'analytique.

Les dashboards les plus consultés mettaient 22 secondes à s'afficher. Concrètement : un client ouvre son rapport de campagne, va se chercher un café, et revient. Certains avaient arrêté de consulter la plateforme et demandaient des exports Excel par email — le pire signal possible pour un produit SaaS.

Chaque nouvelle fonctionnalité analytics aggravait le problème, et l'équipe passait un temps croissant à optimiser des requêtes qui n'auraient jamais dû tourner sur cette base.

Plutôt que d'empiler des index et des caches, j'ai proposé de séparer clairement les deux mondes : MongoDB reste la source de vérité opérationnelle, ClickHouse devient le moteur analytique.

Le travail concret :

• Conception du schéma ClickHouse orienté requêtes (tables dénormalisées, tri par tenant et par date, TTL sur le détail brut).
• Pipeline d'ingestion en Go depuis MongoDB, avec reprise sur erreur et idempotence — le pipeline peut rejouer une journée sans dupliquer une ligne.
• Réécriture des endpoints analytics pour interroger ClickHouse, avec bascule progressive tenant par tenant pour valider les chiffres en parallèle de l'ancien système.
• Validation métier : chaque dashboard migré était comparé à l'ancien sur plusieurs jours avant la bascule définitive.

Le dashboard le plus lourd est passé de 22 secondes à environ 1 seconde. Les clients ont recommencé à utiliser la plateforme en direct pendant leurs réunions — ce qui était impensable avant.

Au-delà du chiffre, l'architecture a débloqué la suite : de nouvelles vues analytics qui étaient simplement impossibles avant sont devenues des fonctionnalités vendables. C'est le projet qui m'a appris qu'un problème de performance est souvent un problème d'architecture déguisé.

Envie du détail technique ? J'ai raconté cette migration dans un article du journal.