Migrer l'accès aux données d'un ERP et transformer le reporting avec Databricks

Le projet en 30 secondes

1. Mon premier vrai projet Data a commencé par une migration

Quand je suis arrivé sur ce projet, je terminais mes études.

My journey était principalement orienté Supply Chain et école de commerce. Je connaissais Excel, j'avais déjà une certaine appétence pour la donnée, mais Databricks, Spark SQL ou l'architecture d'un système d'information industriel étaient encore très loin d'être mon quotidien.

Je rejoignais une équipe Business Process intégrée à la Supply Chain d'une entité appartenant à un grand groupe industriel international.

Et ma mission de départ était assez simple à résumer :

une technologie utilisée pour accéder aux données de l'ERP allait disparaître. Il fallait trouver comment continuer à faire fonctionner tout ce qui en dépendait.

Sur le papier, cela ressemblait à une migration technique.

En pratique, j'allais surtout découvrir comment une donnée voyage depuis un ERP de production jusqu'au fichier ou au dashboard utilisé par quelqu'un plusieurs milliers de kilomètres plus loin.

Et cette découverte a complètement changé ma manière de travailler avec la donnée par la suite.

2. Une échéance qu'on ne pouvait pas repousser

L'entité utilisait encore une solution historique permettant d'interroger certaines données issues de son ERP JD Edwards avec des requêtes SQL.

Au fil du temps, de nombreux fichiers et processus s'étaient construits autour de ce fonctionnement.

Une requête permettait de récupérer certaines informations. L'extraction alimentait ensuite un fichier. Ce fichier était utilisé par une équipe.

Et progressivement, tout un ensemble d'outils métier s'était construit de cette manière.

Le problème était que cette solution historique devait être retirée.

Cela signifiait qu'à une échéance relativement proche, continuer comme avant ne serait simplement plus possible.

Le sujet n'était donc pas :

« Ce serait intéressant de moderniser nos requêtes. »

Le sujet était plutôt :

« Si nous ne faisons rien, certains outils dont les équipes ont besoin ne pourront plus récupérer leurs données. »

Il fallait donc migrer, mais avant de migrer, il fallait comprendre ce que nous avions réellement entre les mains.

3. Avant de réécrire les requêtes, comprendre d'où vient la donnée

Mon maître de stage avait déjà réalisé une partie importante du travail préparatoire.

Il avait notamment recensé les requêtes utilisées et identifié Databricks comme la nouvelle solution permettant de travailler avec les données disponibles dans l'écosystème du groupe.

De mon côté, il fallait maintenant rentrer dans le fonctionnement.

Au départ, j'avais tendance à voir les choses assez simplement :

ERP → requête → Excel.

Puis, progressivement, j'ai commencé à comprendre les différentes couches qui existaient entre ces éléments.

Les données étaient créées dans le système de production et elles alimentaient l'infrastructure Data du groupe.

Databricks permettait ensuite d'interroger cette donnée avec Spark SQL.

Les résultats pouvaient être utilisés par d'autres outils et ces outils pouvaient finalement alimenter les fichiers et reportings utilisés par les équipes.

Architecture conceptuelle illustrative, composants techniques volontairement génériques et ne représentant pas le SI réel.

C'était une manière complètement différente de regarder un fichier Excel.

Le fichier n'était plus le point de départ, il était la dernière étape visible d'une chaîne beaucoup plus grande.

4. Première mission : passer du SQL au Spark SQL

Il fallait d'abord reconstruire ce qui existait déjà.

Les requêtes utilisées avec l'ancienne solution étaient disponibles.

Mon travail a donc commencé par leur migration vers Spark SQL dans Databricks.

Et évidemment, au début, Spark SQL était nouveau pour moi.

Il a fallu apprendre.

Comprendre les requêtes existantes.

Comprendre quelles tables étaient interrogées.

Comprendre les jointures.

Comprendre ce que les utilisateurs attendaient réellement comme résultat.

Puis reconstruire cette logique dans le nouvel environnement.

Le piège aurait été de considérer la migration comme un simple exercice de traduction de syntaxe.

Une requête n'existe pas pour produire du SQL, elle existe pour répondre à un besoin.

Le vrai contrôle était donc beaucoup plus simple :

est-ce que la nouvelle requête restitue bien l'information que l'ancienne permettait d'obtenir ?

Les requêtes ont ainsi été progressivement réécrites, testées et enregistrées dans Databricks.

À mesure que le projet avançait, l'outil qui me paraissait initialement très technique devenait progressivement un environnement de travail normal.

5. Puis j'ai découvert le bouton « Actualiser »

C'est probablement le moment le plus important de ce projet pour moi.

Au départ, le fonctionnement historique restait encore très présent dans ma manière de réfléchir :

une requête produit une extraction, et cette extraction alimente un fichier.

Puis j'ai découvert que les résultats issus de Databricks pouvaient être exploités directement dans Power Query.

Et là, la logique change complètement.

Je n'étais plus obligé de penser :

requête → extraction → téléchargement → fichier.

Je pouvais penser :

requête → connexion → fichier.

Le fichier pouvait être construit une fois, connecté à sa source, puis actualisé lorsque de nouvelles données étaient disponibles.

Cela paraît être une petite différence mais pour moi, à l'époque, c'était énorme.

Le bouton Actualiser remplaçait potentiellement toute une série d'actions humaines.

Et surtout, il rendait possible quelque chose de beaucoup plus intéressant :

construire des outils qui continuent à fonctionner après leur création.

6. Reconstruire les outils existants sans simplement les copier

La mission principale restait néanmoins très concrète.

Il existait des fichiers dépendant de l'ancienne solution et ils devaient continuer à fonctionner.

Je les ai donc repris progressivement et pour chacun, il fallait comprendre :

• à quoi il servait ;

• quelles données il utilisait ;

• quelle requête historique l'alimentait ;

• quelles transformations étaient réalisées ensuite ;

• comment reconstruire le même besoin avec la nouvelle architecture.

La nouvelle requête Spark SQL devenait la source.

Power Query permettait de récupérer et transformer les données.

Puis le fichier pouvait être reconstruit.

Mais tant qu'à reprendre un outil, il n'était pas toujours pertinent de reproduire exactement ses défauts.

Certaines étapes pouvaient être simplifiées.

Certaines transformations pouvaient être intégrées directement au flux.

Certains fichiers pouvaient devenir actualisables au lieu de dépendre d'une nouvelle extraction manuelle.

La migration devenait donc progressivement une occasion de nettoyer et moderniser l'existant.

7. À un moment, nous avons arrêté de simplement remplacer

Une fois suffisamment de requêtes migrées, quelque chose a changé.

Au début, nous utilisions Databricks parce que nous étions obligés de remplacer une technologie condamnée.

Puis nous avons commencé à nous dire :

maintenant que nous savons accéder correctement à cette donnée, qu'est-ce que nous pouvons faire de plus avec ?

C'est à ce moment-là que le projet a dépassé la migration.

Nous ne voulions plus seulement éviter que les anciens outils cessent de fonctionner.

Nous pouvions commencer à construire de nouveaux outils.

Et c'est là que Power BI a pris beaucoup plus de place dans mon travail.

8. Construire des reportings pour des activités situées ailleurs

C'est une des choses qui m'a le plus marqué.

J'étais physiquement dans une petite équipe Supply Chain en France.

Pourtant, grâce à l'infrastructure Data du groupe, je pouvais travailler sur des informations provenant d'activités situées dans d'autres régions ou pays.

J'ai ainsi participé à la création de différents reportings permettant de suivre des sujets liés notamment à la production, la logistique, aux expéditions ou aux activités d'entrepôt.

Les besoins n'étaient plus nécessairement limités à notre site.

Et cela rendait très concret l'intérêt d'une architecture Data centralisée.

Peu importe où se trouvait physiquement l'activité.

Si la donnée remontait correctement dans l'écosystème du groupe et que nous savions comment l'interroger, nous pouvions construire un outil permettant de la suivre.

Schéma conceptuel, architecture simplifiée et illustrative, ne représentant pas l'infrastructure réelle de l'entreprise

C'est à ce moment-là que le projet est devenu particulièrement intéressant pour moi.

Je n'étais plus simplement en train de migrer du SQL.

Je construisais des outils permettant à des personnes de comprendre une activité à partir de données issues de systèmes industriels réels.

9. Derrière le Power BI, encore une fois, il y avait surtout un flux

La partie visible était Power BI.

Mais comme je le comprendrai encore mieux dans mes projets suivants, le dashboard n'est jamais que la dernière couche.

En effet, il fallait d'abord récupérer les bonnes données.

Certaines provenaient de Databricks, d'autres pouvaient venir de fichiers ou de sources complémentaires.

Power Query permettait de préparer et rapprocher ces informations.

Puis venait le modèle de données.

J'ai progressivement travaillé avec des modèles en étoile, différentes dimensions et des mesures construites avec DAX.

Enfin seulement venaient les visualisations, les graphiques, les KPI, les filtres, les slicers, les analyses temporelles et les vues adaptées aux besoins des utilisateurs.

Architecture illustrative, données, modèle et dashboard fictifs

Cette partie du projet m'a particulièrement plu.

Construire un modèle, faire fonctionner les relations, créer les bonnes mesures puis voir progressivement le dashboard prendre forme donnait l'impression de transformer une masse de données difficile à lire en quelque chose d'immédiatement compréhensible.

10. Une migration réussie doit continuer à fonctionner après le départ de celui qui l'a faite

Il y avait cependant une contrainte très particulière dans mon cas.

J'étais stagiaire.

Cela signifie qu'une chose était certaine dès le premier jour :

j'allais partir.

Construire des dizaines de requêtes incompréhensibles que personne ne saurait reprendre quelques mois plus tard aurait donc été une très mauvaise réussite.

La transmission faisait partie du projet.

J'ai créé de la documentation autour des outils et des requêtes.

J'ai également préparé des supports permettant d'expliquer Databricks, son fonctionnement et la manière dont nous l'utilisions.

L'objectif était que quelqu'un puisse arriver après moi et comprendre :

où se trouve la donnée ;

comment les requêtes sont construites ;

comment elles alimentent les outils ;

et comment intervenir lorsqu'une évolution devient nécessaire.

Pour moi, cette partie est aussi importante que le développement lui-même.

Une automatisation que personne ne peut maintenir devient tôt ou tard un nouveau problème.

11. D'une solution de remplacement à un véritable outil de travail

Le résultat le plus intéressant n'est finalement pas le nombre de requêtes migrées.

Au départ, Databricks répondait à une contrainte :

nous devions remplacer une solution qui allait disparaître.

Mais progressivement, l'équipe a commencé à utiliser la nouvelle plateforme pour beaucoup plus que cela:

Nouvelles requêtes.

Newx fichiers.

Newx reportings.

Nouvelles analyses.

Au fil du projet, notre petite équipe Business Process est devenue une utilisatrice particulièrement active de Databricks, malgré sa taille relativement réduite.

C'est probablement l'un des meilleurs indicateurs de réussite de la migration.

La nouvelle technologie n'avait pas simplement remplacé l'ancienne.

Elle avait créé de nouveaux usages.

12. Ce projet a surtout changé ma façon de regarder Excel

C'est probablement le résultat le plus important pour mon parcours personnel.

Avant ce projet, lorsque je regardais un fichier Excel, je regardais principalement ce qu'il contenait.

Après ce projet, j'ai commencé à regarder d'où venait ce qu'il contenait.

C'est une différence assez fondamentale.

Une cellule affichant un chiffre n'est que le dernier maillon.

Derrière, il peut y avoir :

un ERP ;

une infrastructure Data ;

une requête ;

des transformations ;

un modèle ;

une mesure ;

puis enfin la valeur affichée à l'utilisateur.

Et une fois qu'on commence à penser comme ça, beaucoup de problèmes deviennent différents.

Plus tard, je me retrouverai face à un autre ERP, cette fois dans un environnement beaucoup plus fermé, sans infrastructure Data directement accessible ni connexion native vers mes outils d'analyse.

Mais je ne chercherai pas à reproduire Databricks.

Je chercherai à reproduire le principe que j'avais appris ici : construire un chemin entre la donnée source et l'utilisateur.

Les technologies étaient différentes. Le raisonnement était le même.

13. Les contraintes d'un grand groupe changent aussi la manière de construire

Ce projet était très différent de certains systèmes que j'ai pu développer ensuite.

Je n'étais pas administrateur de tout, je ne pouvais pas décider seul de modifier l'architecture, je travaillais dans un écosystème informatique existant, avec ses outils, ses règles, ses droits d'accès et ses choix technologiques et c'était justement intéressant.

Il fallait construire à l'intérieur d'un système beaucoup plus grand que mon propre projet.

Databricks existait déjà dans l'écosystème du groupe, l'infrastructure Data existait, l'ERP existait, Power BI existait.

Mon travail consistait à comprendre comment utiliser correctement ces briques pour répondre aux besoins de notre équipe.

C'est une autre forme d'automatisation.

Parfois, il faut inventer une architecture presque de zéro.

Parfois, les briques existent déjà et le vrai travail consiste à comprendre comment les assembler intelligemment.

14. Ce que je retiens de ce projet

Quand j'ai commencé ce stage, Databricks et Spark SQL étaient presque un nouveau langage pour moi.

Quelques mois plus tard, j'avais migré des requêtes, reconstruit des outils, connecté des données avec Power Query, participé à la création de reportings Power BI et créé de la documentation permettant à d'autres personnes de reprendre le travail.

Mais ce n'est pas vraiment la liste des technologies que je retiens.

Ce projet m'a surtout appris à suivre une donnée:

Comprendre où elle est créée.

Comprendre comment elle devient accessible.

Comprendre comment l'interroger.

Comprendre comment la transformer.

Puis comprendre comment la présenter à la personne qui en a réellement besoin.

C'est aussi là que j'ai compris quelque chose qui influence encore aujourd'hui presque tous mes projets Data :

une extraction manuelle ne devrait pas être considérée comme une fatalité simplement parce qu'elle a toujours été faite comme ça.

Si la donnée existe et qu'un chemin fiable peut être construit jusqu'à l'utilisateur, alors ce chemin mérite d'être étudié.

Et parfois, le changement le plus important pour l'utilisateur final tient simplement dans un bouton :

Actualiser.

Une migration technique peut être l'occasion de repenser beaucoup plus

Une technologie arrive en fin de vie, un ERP change, une source de données disparaît, un reporting devient impossible à maintenir...

À première vue, ce sont des problèmes techniques.

Mais ils peuvent aussi être l'occasion de se poser une question plus intéressante :

est-ce qu'on doit vraiment reconstruire exactement ce que nous avions avant ?

Parfois oui.

Mais parfois, une migration est justement le bon moment pour supprimer des extractions manuelles, reconnecter les outils à leurs sources, revoir les modèles de données et construire quelque chose qui sera plus simple à utiliser demain.

C'est ce qui s'est passé sur ce projet.

Nous devions préserver l'accès à la donnée.

Nous avons finalement appris à beaucoup mieux l'utiliser.