Avant le big data, il y a le rangement

Ce que big data veut dire en pratique

Le volume est rarement le problème. Une société de deux cents personnes produit des données qui tiennent sans difficulté dans PostgreSQL ou SQL Server, avec plusieurs années d'historique. Ce qui fait mal, c'est que la même notion existe sous cinq formes dans cinq systèmes et que personne ne sait laquelle fait foi.

Le travail utile consiste donc à choisir un endroit où la donnée arrive, à écrire les pipelines qui l'y amènent tous les jours sans surveillance, et à décider une fois pour toutes ce qu'est un client, une commande et une machine. Ce n'est pas vendeur. C'est ce qui change des décisions.

Un tableau de bord que personne n'ouvre est un échec

C'est le livrable le plus courant du métier et le plus inutile. Il est joli, il a coûté cher, il a été présenté une fois, et trois mois plus tard il est faux parce que personne ne l'a regardé assez souvent pour s'en apercevoir.

Nous partons donc de la décision, pas de l'écran. Quelle décision doit changer, qui la prend, à quelle fréquence, et quel chiffre lui manque aujourd'hui. Si aucune décision ne change, il n'y a pas de projet, et il vaut mieux le dire avant qu'après.

Si les sources se contredisent, aucun pipeline ne règle ça

Quand l'ERP et le CRM annoncent deux chiffres d'affaires différents, la question n'est pas technique. Quelqu'un doit trancher ce qui compte comme une vente, à quelle date, et ce qu'on fait des avoirs et des remises. Tant que cet arbitrage n'est pas rendu, un pipeline ne fait que recopier le désaccord plus vite.

Nous documentons les écarts, nous les chiffrons et nous les remontons. La décision appartient au métier. Notre travail commence une fois qu'elle est prise, et il consiste à faire en sorte qu'elle soit appliquée partout de la même manière.

Ce que nous construisons réellement

Un entrepôt sur PostgreSQL ou SQL Server, hébergé sur Azure, avec les pipelines d'ingestion qui vont avec, écrits en .NET ou en Node. Le déploiement passe par Docker, Terraform et GitHub Actions, comme le reste de ce que nous livrons, pour que reconstruire l'ensemble soit une opération connue et pas une aventure.

Nous avons remonté des données machine vers Azure en environnement industriel et intégré des ERP et des MES. Ce type de flux n'a rien de glamour : il tombe la nuit, il reçoit des valeurs aberrantes, il reçoit deux fois le même message. La qualité d'un pipeline se juge à ce qu'il fait dans ces cas-là, pas au schéma d'architecture.

Pour la restitution, nous branchons l'outil que vous avez déjà. Personne n'a besoin d'un outil de visualisation supplémentaire.

Là où nous sommes la mauvaise réponse

Si vous avez déjà un entrepôt propre et que le besoin porte sur la modélisation ou l'analyse métier, prenez un analyste ou un cabinet BI. Nous construisons la plomberie. Nous ne sommes pas votre équipe d'analystes.

Si votre besoin est de la recherche en apprentissage automatique, un modèle à concevoir et à entraîner, ce n'est pas notre terrain. Nous savons mettre un modèle existant en production et le faire tenir dans la durée. Nous ne sommes pas un laboratoire.

Et si vos données tiennent dans un tableur que trois personnes maintiennent correctement, gardez le tableur. Le moment de construire arrive quand les allers-retours manuels entre systèmes coûtent plus cher chaque mois que la plomberie qui les supprimerait.