Delio Amato (Geodis) : « nous voulons favoriser l’usage de la data par toute l’entreprise »

Pouvez-nous présenter Geodis ?

Geodis est présent sur l’ensemble des métiers du transport et de la logistique pour le monde entier, de la messagerie au transport intercontinental en passant par les transports routiers et la logistique. Filiale à 100 % du Groupe SNCF, nous avons une présence directe dans plus de soixante pays et une desserte de 166 pays. Avec plus de 1000 sites et 53 000 collaborateurs, nous disposons de près de dix millions de mètres-carrés et nous générons 11,6 milliards d’euros de chiffre d’affaires.

Aussi bien en tant que chief data officer qu’en tant que chief architect officer de Geodis, je suis rattaché à François Bottin, vice-président exécutif du groupe, Chief Digital & Technology Officer.

Comment est architecturé votre SI et notamment votre data ?

A l’origine, notre SI est relativement décentralisé et siloté entre les différentes entités (régions, métiers…) et c’est évidemment vrai aussi pour la data. Au niveau groupe, nous avions seulement des applications type finances, RH, CRM, et Bus d’Entreprise par exemple.

Il y a cinq ans, nous avons voulu mettre en place une approche globale avec une offre end-to-end pour nos clients. Or, à l’époque, méthodologies et technologies étaient hétérogènes et rendaient cette approche concrètement impossible. La première étape devait donc être de créer une capacité technologique à partager la donnée, ce qui passait par l’usage d’une plateforme dédiée. Et c’était une première expérience dans le cloud, en l’occurrence Azure.

Quels choix technologiques avez-vous faits et pourquoi ?

Nous avons voulu éviter d’être lié avec un seul fournisseur et un seul cloud et même avoir la capacité de passer en tout ou partie en on premise. Il nous fallait donc une plateforme hybride, portable, ouverte et réversible. Cela passait par un outil open-source. En l’occurrence, nous avons choisi Cloudera avec, au fil du temps, des outils complémentaires (Kafka, Starburst…).

Chacun peut ainsi créer ses propres cas d’usages sur ses propres données mais aussi partager et les laisser en libre-service au profit des autres directions.

Aujourd’hui, notre but est de passer à un stade plus avancé pour favoriser la consommation de toute la data par toute l’entreprise. Pour cela, nous allons adopter une approche en data products.

Depuis le début de sa conception, la plateforme devait pouvoir traiter tous les cas d’usage, de l’analytique de masse aux temps de traitement temps réel opérationnel métiers. Nous avons donc déployé une pluralité de moteurs de bases de données (data lake, NoSQL…).

Mais est-ce que cela ne complique pas le fameux accès dans toute l’entreprise de toutes les données ?

De fait, plusieurs bases de données, c’est plusieurs moteurs, plusieurs modalités d’accès, plusieurs syntaxes, etc. Nous avons déployé Starburst comme porte d’entrée unique pour tous les cas d’usage, pour toutes les technologies sous-jacentes. En plus, nous avons gagné en performance.

Nous utilisons peu la capacité de virtualisation des données pour pré-requêter au travers des vues. Et nous n’avons pas encore déployé les tables virtuelles pour regrouper logiquement les données.

Starburst a une capacité à gérer des data products que nous n’utilisons pour l’instant que pour la présentation des données aux utilisateurs. Mais des data products, ce ne sont pas seulement au stade final. Il faut considérer les produits sur l’ensemble du cycle de vie. Nous menons donc actuellement une évolution de notre plateforme pour étendre le rôle de Starburst pour en faire un moteur d’exécution SQL unique sur l’ensemble de notre patrimoine data. Quand ce sera fait, nous pourrons pleinement exploiter ses capacités de gestion de data products au bénéfice de l’ensemble des consommateurs de la donnée (finaux, intermédiaires…).

Starburst a été très bien adopté par la communauté des développeurs.

Quels sont vos défis ?

Les défis sont surtout techniques car l’écosystème de la data évolue très vite.

Nous devons simplifier la maintenabilité de la plateforme. Au lieu de gérer nous mêmes celle-ci dans notre propre cloud, ce qui n’a pas beaucoup de valeur mais est très chronophage, nous pourrions recourir au service managé de Starburst. Mais cela a des conséquences en gestion de la sécurité, gestion du catalogue, etc. Il y a du travail !

Pour rendre plus accessible la data à plus de monde (notamment des populations moins expertes), nous utilisons depuis un an Dataiku. Il nous reste à bien l’intégrer avec Starburst.