Projets

Comment Bolloré Transport & Logistics construit ses micro-services d'entreprise

---

Bolloré Transport & Logistics s'appuie sur la plateforme Kafka de Confluent pour créer ses propres « enterprise micro-services » au dessus de services SaaS standards. Cette architecture découplée et orientée événements lui a permis de transformer son système d'information et de se tourner vers le cloud.

PublicitéLors de la conférence Data In Motion organisée par Confluent, Pierre-Raymond Pouligny, qui dirige la cellule architecture et cloud public chez Bolloré Transport & Logistics, a expliqué le rôle clef de la plateforme Kafka fournie par l'éditeur dans la transformation digitale de l'entreprise, un opérateur de transport et de logistique d'envergure mondiale. La solution permet en effet à Bolloré Transport & Logistics de profiter du cloud public, tout en pouvant bâtir par-dessus ses propres micro-services d'entreprise, afin de conserver la maîtrise des fonctionnalités apportant de la valeur.

« La cellule architecture compte trois sous-directions : architecture d'entreprise, architecture software et architecture cloud. Son rôle est d'accélérer la transformation digitale du groupe », a décrit Pierre-Raymond Pouligny. Pour expliquer la place de l'architecture dans la transformation, il a ensuite retracé un bref historique du système d'information du groupe. Quand ce SI a commencé à se constituer, dans les années 90-2000, une grande partie a été conçue sous forme de développements spécifiques - avec les avantages et les inconvénients associés. « Entre 2015 et 2020, nous avons vu émerger sur le marché des logiciels pertinents pour nos métiers de la logistique. Des solutions simples à acquérir, performantes, mais qui présentaient néanmoins elles aussi des limites : dépendance à un tiers, perte de l'identité d'entreprise et de ses différenciateurs. Enfin, nous n'avions nulle garantie que la meilleure solution d'alors serait la même dans deux ans », a pointé Pierre-Raymond Pouligny. Mais depuis peu, une partie importante de ces solutions du marché sont proposées sous forme de micro-services découplés, ce qui a rebattu les cartes. « Le micro-service vendu est celui de l'éditeur, il peut couvrir 80% du besoin, qui est standard. Mais il reste 20%, qui font la valeur de l'entreprise. Il fallait donc trouver un moyen d'enrichir ces micro-services, pour en faire des micro-services d'entreprise », a expliqué le chef de la cellule architecture.

Nouveau pattern d'architecture

Cette réflexion a conduit Bolloré Transport & Logistics à mettre en place un nouveau pattern d'architecture, dénommé Cargo, dans le cadre d'un programme de transformation de l'expédition du fret. Prévu sur cinq ans, celui-ci a débuté en 2020 et couvre 12 000 utilisateurs sur 106 pays. « Avec le pattern Cargo, il ne s'agit pas simplement d'ajouter une API, mais un vrai micro-service, car dans le micro-service que nous consommons, les données que nous voulons proposer ne figurent pas forcément. Pour bâtir ces micro-services d'entreprise, nous combinons les micro-services de nos solutions SaaS avec les nôtres, en adaptant, en étendant voire en transcodant les API », a détaillé Pierre-Raymond Pouligny. Le prérequis pour pouvoir intégrer micro-services SaaS, internes et données était de disposer d'un pipeline de connexion, ou middleware orienté messages (MOM). « Nous devions disposer de notre propre bus, car nous utilisons des formats de message qui nous sont propres », a indiqué Pierre-Raymond Pouligny. Cette couche intermédiaire était indispensable, notamment pour pouvoir déployer un data lake as-a-service, nécessaire pour rationaliser les systèmes de gestion du transport. Elle devait également être performante, car chaque couche ajoutée peut se traduire par un ralentissement des processus. Ces raisons ont conduit le groupe à choisir la plateforme de streaming d'événements de Confluent. Grâce à cette architecture découplée et orientée événements, les équipes de développement peuvent bâtir des micro-services d'entreprise et les utiliser directement à travers le MOM Confluent, y compris depuis les applications Legacy sur AS/400. « Nous pouvons ainsi consacrer 80% de nos efforts aux 20% de fonctionnalités qui apportent de la valeur à l'entreprise, et 20% sur les 80% restantes, qui sont couvertes par des progiciels en SaaS », a souligné Pierre-Raymond Pouligny. « Nous n'interdisons pas l'utilisation des micro-services SaaS, mais l'inconvénient est le couplage fort avec ces derniers », a-t-il ajouté.

PublicitéSi la mise en place d'un tel pattern reste compliquée selon Pierre-Raymond Pouligny, en l'espace d'un an, beaucoup a déjà été accompli. « Nous avons mis en place un core model pour le passage au cloud MS Azure, déployé un data lake sur MongoDB Atlas, mis celui-ci à disposition sous forme d'un data lake as-a-service à travers Confluent Kafka... Nous avons également revu nos façons de travailler, passant d'une organisation bicéphale à tricéphale, avec les équipes fonctionnelles, les équipes de développement et l'équipe d'architecture. » Un premier produit basé sur Cargo a été construit, pour la gestion des ordres de transport (Transport Order Management). « Entre le front office et la gestion des achats intervient tout un enrichissement, avec des outils de cotation et d'optimisation des trajets qui reposent sur des micro-services achetés ou déjà présents. Ces micro-services sont encapsulés dans le produit, qui possède sa propre interface utilisateur », a décrit Pierre-Raymond Pouligny. Un deuxième produit basé sur le pattern vient juste de sortir, et d'autres sont prévus, la seule condition étant de pouvoir bénéficier de produits du marché vendus sous forme de micro-services.

Un langage commun

Du chemin parcouru, Pierre-Raymond Pouligny a tiré quatre enseignements clefs pour réussir. D'abord, il faut s'assurer que les progiciels choisis reposent sur une véritable architecture cloud, sans quoi l'élasticité recherchée ne pourra pas être atteinte. Ensuite, une collaboration étroite entre les développeurs et architectes est nécessaire pour appliquer le pattern de façon efficace et pertinente. Les équipes architecture ont dénommé cette approche : « Make Cargo not Cargo Cult », l'objet étant de ne pas faire de l'architecture pour de l'architecture. L'accompagnement du changement est lui aussi fondamental, « car cette vision où l'architecture collabore avec le développement et les métiers est nouvelle ». Enfin, il faut impérativement un langage unique et partagé, avec des définitions claires des flux de données. « Pour définir ce langage, nous avons utilisé des ateliers d'event storming », a précisé Pierre-Raymond Pouligny.

Article rédigé par

Aurélie Chandeze, Rédactrice en chef adjointe de CIO
Suivez l'auteur sur Linked In,

Partager cet article