Il y a une métrique qu'aucun outil de monitoring ne vous donne : le nombre de clients qui ouvrent votre dashboard, soupirent, et vont se chercher un café.
Sur la plateforme SaaS retail sur laquelle je travaillais, cette métrique était élevée. Le dashboard principal — celui que les clients ouvrent en réunion pour montrer les résultats d'une campagne — mettait 22 secondes à s'afficher. Vingt-deux secondes. En réunion. Devant un directeur marketing.
Certains clients avaient trouvé la parade : ils demandaient des exports Excel par email. Quand vos utilisateurs préfèrent un fichier Excel à votre produit, ce n'est plus un bug de performance. C'est un signal d'alarme.
Le vrai problème n'était pas la lenteur
La tentation, face à une requête lente, c'est de l'optimiser. Un index par-ci, un cache par-là. On l'a fait. Chaque optimisation gagnait 2 ou 3 secondes... jusqu'à la fonctionnalité suivante qui les reprenait.
Le vrai problème était ailleurs : on demandait à MongoDB, une base pensée pour le transactionnel, de faire un travail d'entrepôt analytique. Agréger des millions de lignes à la volée, ce n'est pas son métier. Aucun index ne change ça.
C'est une leçon que je re-croise partout depuis : un problème de performance chronique est presque toujours un problème d'architecture déguisé. Si vous optimisez la même zone pour la troisième fois, arrêtez d'optimiser. Le message est ailleurs.
Séparer les deux mondes
La solution retenue : laisser MongoDB faire ce qu'il fait bien — le transactionnel, la source de vérité — et confier l'analytique à ClickHouse, une base colonne pensée exactement pour ça.
Sur le papier, c'est un schéma d'architecture propre. En vrai, le travail était moins glamour :
- Un pipeline d'ingestion en Go, dont la propriété la plus importante n'est pas la vitesse mais l'idempotence : pouvoir rejouer une journée entière après un incident sans dupliquer une seule ligne. C'est le genre de propriété qu'on n'apprécie que le jour où on en a besoin. Ce jour arrive toujours.
- Un schéma ClickHouse pensé à l'envers : on part des requêtes des dashboards, et on dessine les tables pour elles. Dénormalisé, trié par tenant et par date. Ça pique quand on vient du monde relationnel, et c'est exactement ce qu'il faut.
- Une bascule progressive, tenant par tenant, avec les deux systèmes en parallèle pendant plusieurs jours pour comparer les chiffres. Parce qu'un dashboard rapide mais faux est pire qu'un dashboard lent.
Le moment qui compte
Le dashboard est passé de 22 secondes à environ 1 seconde. Mais le vrai résultat, ce n'est pas le chiffre.
C'est un client qui rouvre la plateforme en pleine réunion, clique sur trois filtres d'affilée, et ne remarque rien. La performance réussie est invisible : elle ne s'applaudit pas, elle se constate dans le silence des gens qui utilisent votre produit sans y penser.
Et il y a un effet second, plus intéressant encore : des fonctionnalités analytics qui étaient impossibles avant — trop lourdes, trop lentes — sont devenues envisageables, puis vendables. Une bonne architecture ne se contente pas de réparer le présent. Elle rouvre le futur.
Si vous vivez avec un dashboard à 20 secondes et une pile de tickets "optimiser la requête X" : je suis passé par là. Écrivez-moi, je vous dirai ce que je referais — et ce que j'éviterais.