Visualiser les KPI de son entreprise en temps réel

Le contexte

Nous sommes en fin d'année 2018, comme beaucoup de e-commerçant, Une Petite Mousse réalise une part significative de son chiffre d'affaires à Noël. Le rush commence généralement autour de la mi-octobre.

Au plus fort du rush, l'équipe est gonflée à bloc. Les demandes de clients afflues, les ventes pleuvent, les camions passent au moins 2 fois par jour à l'entrepôt : c'est la folie. Littéralement.

Dans ces moments, là, il peut être compliqué de rester concentré sur le coeur de l'activité : la vente de notre produit phare. On a très peu de temps à accorder aux analyses des données de ventes, et pourtant, on connait très bien leur importance.

C'est pourquoi nous avions pris la décision d'accorder du temps en amont du rush à la création d'un tableau de bord de suivi des ventes en temps réel, accessible à tous les salariés.

Au delà du besoin métier, nous souhaitions aussi créer une certaine cohésion autour des objectifs de vente (#espritdequipe)

Ce type de reporting est inclus dans la plupart des solutions e-commerce "grand public", mais quand on tourne sur une application Symfony... et bien pas du tout ! De plus, la partie "temps réel" du besoin changeait la donne.

Nous avions défini le besoin suivant :

Installation d’un écran de télévision en salle de pause, affichant en temps réel les indicateurs clés identifiés, et donnant la possibilité à n’importe qui d’interagir avec les données.

Les outils à disposition

Pour ce type de projet de visualisation de données, on a plein d'outils possibles. Celle qui a retenu notre attention, c'est Metabase : The fastest, easiest way to share data and analytics inside your company.

En plus des fonctionnalités de base d'un outil de BI (les tableaux de bords notamment) Metabase présentait son avantage principal comme étant la possibilité donnée à tous les salariés de poser directement des questions à l'outil, et d'obtenir des réponse.

Bien sûr, pour l'utilisateur lambda, pas question d'écrire du SQL ou autre requête; "juste" une interprétation de la question formulée en bon français : "Combien de bières a-t-on vendu hier ?", ou encore "Quel est le chiffre d'affaires de la semaine ?"

Incroyable ! On a donc choisi d'implémenter cet outil.

Avant de pouvoir visualiser des données, il nous faut........ des données. Ça paraît bête, oui, mais cela pose pleins de questions. Les 2 principales étant :

• quelles sources de données retenir ?
• comment garantir la sécurité ?

Lorsque l'on parle de BI, ce sont 2 points cruciaux. Pas question de retrouver toutes nos données en accès libre sur le web. Pas question non plus de présenter des données faussées.

Metabase propose plusieurs solution d'installation. La première, et la plus simple, consiste à télécharger une application, qui tourne en local. Idéal pour se faire une première idée des possibilité offertes par l'outil avant de pousser plus loin, je pars là dessus. Une instance mysql locale alimentée avec un dump de la machine de production suffit pour un démarrage rapide.

Je valide assez rapidement : les tableaux sont propres et l'interrogation de la base de données se fait naturellement en SQL. Ça avance.

J'avais découpé le projet en 3 livrables distincts :

• Obtenir un tableau de bord interactif et temps réel disponible sur un environnement local.
• Obtenir un tableau de bord interactif disponible sur une url dédiée (à ce stade, on peut présenter le résultat sur un ordinateur quelconque)
• Obtenir un tableau de bord affiché en temps réel sur un téléviseur installé en salle de pause/hall d’accueil

Il me manquait à ce stade l'aspect "temps réel" pour couvrir l'ensemble du premier livrable.

J'ai toujours considéré l'environnement de production du site comme un endroit "sacré", ou en tout cas... un endroit où je devais aller le moins possible pour éviter les problèmes. Ça m'aurait épargné beaucoup d'effort mais c'était ma philosophie. J'ai donc opté pour une autre approche qui consistait simplement à récupérer les dump de sauvegarde de la base, sur un bucket S3. Assez loin de la base de production pour éviter tout problème, et assez "frais" pour être considéré comme "temps" réel.

Concrètement, j'ai mis en place une tâche CRON sur ma machine pour :

• Récupérer le dump sql le plus frais depuis le bucket S3, vers ma machine
• Charger ce dump sur mon instance mysql locale

Et voilà, objectif #1 rempli. C'est maintenant que les choses vont se corser.

Pour rendre les dashboard accessible à toute l'équipe, il fallait pouvoir l'héberger.

Toute l'infrastructure actuelle étant basée sur AWS (le service de Cloud Computing d'Amazon), nous avons décidé de partir sur une instance EC2 comme serveur applicatif, avec un OS Ubuntu.

Metabase propose une version Dockerisée de son application. Ça tombait très bien puisque l'on avait adopté cet outil (Docker) depuis un peu plus d'un an, et notre Dev en Chef ne jurait que par cela.

J'installe donc Docker sur la machine EC2, et déploie le conteneur Metabase dans son plus simple appareil :

docker run -d -p 3000:3000 --name metabase metabase/metabase

Le miracle de la vie arrive assez vite et on affiche bien la page d'accueil de l'application. Première victoire :

Bien sur, je ne pouvais pas encore construire là dessus, il me manquait un élément clé, particulièrement sur une application Docker : la persistance des données.

Comprenez : la sauvegarde du contenu de l'application en dehors du conteneur Docker (i.e. sur la machine hôte).

docker run -d -p 3000:3000 -v ~/metabase-data:/metabase-data -e "MB_DB_FILE=/metabase-data/metabase.db" --name metabase metabase/metabase

Là encore, ce n'est pas suffisant pour avoir une installation réellement robuste. Mais le temps file et nous sommes déjà en Novembre : la vague approche.

Je met donc rapidement en place le même principe de récupération de dump sql depuis la prod, vers cette nouvelle machine. Je passe bien sûr par un tunnel SSH pour garantir un minimum de sécurité.

Je me complique ensuite un peu la vie, par manque de connaissance sur Docker.. au lieu de charger ce dump sur un conteneur docker mysql, qui aurait alors pu être interrogé directement par Metabase... je créé un intermédiaire : une base sql locale, sur laquelle je charge le dump issu de S3, que je transfert vers l'instance MySql dockerisée... honnêtement, en écrivant ces lignes quelques années après... j'ai presque honte. L'explication est assez simple : la récupération des données depuis S3 se faisait à l'aide d'un script bash qui récupérait le dump et le chargeait dans une instance locale. Je n'avais juste pas les connaissance nécessaires pour modifier ce script et charger le dump directement dans l'instance mysql dockerisée. Voilà.

Bref, l'essentiel était là : le 2° objectif était atteint.

Restait le 3° et dernier : rendre le tout visible à tous, en salle de pause.

Petite parenthèse : pourquoi la salle de pause ?

On avait au départ un peu peur du côté "anxiogène" que pourrait avoir cet écran. Mais la configuration des bureaux, de l'entrepôt et de la brasserie, faiait que c'était le seul lieu de vie commune dans lequel ne circulait pas du publique. Et puis, tout le monde trouvait ça plutôt fun et finallement, plutôt "honnête" de voir concrètement comment se déroulaient les ventes. Fin de la parenthèse.

Il y avait là encore pleins de façon de faire. J'ai cette fois-ci pris la plus simple : un ordinateur, un écran, un navigateur et la fonction "auto referesh toutes les 15 minutes" de Metabase.

Voilà, objectif atteint.

Bilan

Avec du recul, il y a certaines choses que j'aurai faites différemment. Mais avec mes connaissances de l'époque, je pense être allé assez loin pour être satisfait du travail.

Par la suite, j'ai renforcé un peu l'application : base de données applicative migrée vers du PostreSQL et connexion à d'autres sources de données notamment. J'ai même expérimenté Metabot : un bot Slack à qui on pouvait directement poser nos questions et qui répondait avec les données de Metabase.

En vérité, mon infrastructure était un peu trop bancale et surtout beaucoup trop lourde pour que Metabot soit efficace. Pour les connaisseurs, on parle pourtant d'une instance m3.medium, imaginait les ressources que je consommais...

La fonctionnalité que l'équipe à le plus apprécié était le fait de recevoir chaque matin, dans un canal Slack dédié, les informations de ventes de la veille.

La plus belle surprise du projet, au delà de l'aspect purement technique, c'était de voir la mobilisation de l'équipe autour des objectifs commerciaux. Pleins de questions et d'émulsion autour de ces tableaux bords.

Je pense que le fait de rendre "visible" et assez tangible des notions assez distantes (des objectifs de vente), dans une société où le magasin est par définition intangible (le site de vente) apporte une valeur ajoutée incroyable.

Le rêve secret de notre DAF à ce moment, était d'avoir ces indicateurs financiers, dans le même type de dashboard. Le mien, était d'avoir le ROI (et pas seulement le ROAS) de nos campagnes en direct.

Pour répondre à ce type de besoin, on rencontre une nouvelle problématique :

• La consolidation de sources multiples

C'est un besoin que Metabase ne couvre pas.

C'est le rôle d'un outil que l'on appelle un ETL : Extract Transform and Load. Et c'est l'objet d'une autre histoire ;)