Accompagner l’ambition de transformation du groupe PAREDES en assurant l’interopérabilité au sein du SI

PAREDES a révolutionné le monde de l’hygiène en France en créant le marché de l’usage unique. Depuis plus de 7 décennies, ce groupe de plus de 650 collaborateurs, fabrique et distribue des produits et des solutions innovantes en matière d’hygiène et d’équipements de protections individuelles pour les professionnels. Leur approche, fondée sur leurs valeurs, est celle d’une entreprise résolument orientée Client.

La gestion des flux de données au sein du système d’information est une problématique présente dans tousles secteurs d’activité, renforcée par la taille de l’entreprise, la diversité des applications métiers ainsi que les besoins de digitalisation et d’intégration avec l’écosystème.

Quelles évolutions de l’entreprise ont impacté la direction des systèmes d’information ces dernières années ?

Avant tout, pour poser le contexte, nous ne sommes qu’au début de notre trajectoire de transformation ! Elle va se poursuivre dans les années à venir. La DSI est au cœur de la transformation de PAREDES : notre objectif est de remettre PAREDES en dynamique et se donner la capacité d’évoluer en permanence.

Ce programme de transformation repose sur plusieurs dimensions, avec en particulier le fait de recentrer le business vers des secteurs de marché où PAREDES a une vraie valeur à apporter aux clients. C’est le cas par exemple des secteurs de la Santé, des Collectivités, des Entreprises de Propreté et de l’Industrie.

La deuxième dimension essentielle est d’accélérer sur le digital. Auparavant, 90% des processus de PAREDES reposaient sur l’ERP. Le programme de transformation vise à ouvrir en grand des solutions digitales pour nos clients : portail clients, plateforme e-commerce… C’est-à-dire des solutions qui vont projeter PAREDES vers l’extérieur et qui doivent aussi communiquer entre elles !

Si on remonte un peu dans le temps, cela fait aussi écho à la place grandissante des métiers. De plus en plus, ils nous faisaient remarquer que « l’ERP c’est bien, mais sur tel ou tel bout de process ce n’était pas pérenne » ou qu’ « il fallait raccorder le SI avec telle nouvelle application best of breed, ou développée en interne. » et leurs besoins s’accéléraient.

Notre objectif : partager l’information de façon fluide, efficiente, orchestrée et supervisée, d’abord en interne puis avec l’extérieur.

Quels enjeux vous ont convaincus qu’une plateforme ESB était indispensable pour soutenir cette transformation ?

L’interopérabilité au sein des briques du système d’information de Paredes est devenue un vrai enjeu quand on a commencé à hybrider le SI et à sortir des données de l’ERP pour les faire circuler plus largement. Tant que tout tournait dans l’ERP, nous étions sur des schémas très traditionnels de demi-interfaces. L’orchestration et la supervision étaient alors empiriques et manuelles.

Historiquement, il y avait déjà une somme de projets (Power BI, EDI…) qui s’était traduite par la mise en place d’échanges de données mono ou multi-sens, sans qu’ils soient posés dans un plan de travail permettant de superviser les flux. C’est l’ERP qui fédérait les flux : l’application métier déposait son fichier dans un dossier que l’ERP scannait avec une fréquence définie. Si le timing n’était pas le bon, les échanges pouvaient se télescoper !

Entre fin 2018 et 2021, beaucoup de choses ont changé. Nous avons accumulé un certain nombre de projets et les formats d’échange se diversifiaient de plus en plus. Plus ils se développaient, plus nous savions que nous allions être confrontés à des mécanismes d’interopérabilité avec des enjeux de fréquence et de qualité. La technique d’autrefois n’était plus suffisante ! Comment également répondre à notre volonté d’échanger avec le reste du monde ? D’extraire, mutualiser la donnée et la distribuer vers plusieurs applications ?

Ces dernières années, nous avons doublé quasiment tous les ans le nombre de flux. Or, orchestrer les flux n’est plus une option à un certain niveau de volumétrie et de fréquence !

Le début du projet e-commerce fut la première des briques majeures du programme de transformation qui a mis en lumière le besoin très fort d’interopérabilité.  De nombreux autres projets étaient aussi concernés comme le CRM (Microsoft Dynamics) qui devait communiquer via API. Impossible à faire au travers de l’ERP dans sa version actuelle !

A la fin de l’été 2020, nous étions ainsi convaincus de la nécessité de mettre en place une plateforme d’échange nous permettant de collecter l’information et de la redistribuer, quelle que soit la technologie utilisée. Et cela, d’autant plus que nous avions fait précédemment quelques essais avec Azure Data Factory. Cette approche était technologiquement très intéressante, mais loin d’être adaptée à notre contexte dans la pratique. Nous ne souhaitions pas multiplier les éditeurs et nous sommes « pro Microsoft », mais quand on ne trouve pas de solution adéquate, il faut ouvrir !

C’est pour cela que nous souhaitions mettre en œuvre une mécanique avec un entrepôt de données alimenté par l’ESB ou l’ETL. Notre crédo était de développer des échanges plus fluides et mutualisés.

Quelles ont été les grandes étapes de la sélection et de la mise en place de la plateforme ESB ?

Quand est arrivé le projet CRM avec des échanges de nature très diverse, nous savions que l’ETL ne répondrait pas au besoin. Au sein d’Azure Data Factory, tous les services sont parcellaires et ne sont pas rassemblés dans un outillage cohérent de notre point de vue. Le budget était également un frein.

Les premiers travaux autour de notre e-commerce notamment, et SSIS (SQL Server Integration Services) nous ont permis de rencontrer les équipes de Data-Major. Nous avons commencé à collaborer sur d’autres dossiers, puis nous avons réfléchi ensemble à ce sujet de gestion des flux inter-applicatifs et nous nous sommes retrouvés autour de plusieurs convictions.

Fin de l’été 2020, la décision était prise. Le temps d’écrire l’expression de besoin, de s’accorder avec l’intégrateur sur la logique du « Why not », le projet CRM a démarré et les premiers flux ont été conçus. Nous avons ensuite installé la plateforme en janvier 2021, formé en février, et lancé le premier lot sur la CRM avec les équipes de Data-Major pour une rentrée en production en Q4 2021.

Je voulais une approche simple, moderne, économiquement accessible, qui aille vite, dans la logique d’un « Why not ? » et avec un partenaire intégrateur prêt à s’investir dans la démarche. Je souhaitais également pouvoir souscrire en On-Premise.

Au niveau du choix de la plateforme ESB, nous avions étudié plusieurs solutions. La majorité d’entre elles était très technologique. Face à cela, l’approche low-code de Blueway nous a paru extrêmement intéressante, tout comme le fait d’ajouter par la suite des modules pour évoluer vers des besoins complémentaires, sans contraintes : MDM, BPM… Cette ouverture, c’est un élément de réflexion que nous gardons en tête pour une future démarche MDM ! Cela fait partie des critères qui ont renforcé nos convictions. Lorsque nous lancerons un chantier MDM, on se donne ainsi la possibilité d’avoir un encapsulage natif avec l’ESB. Et cela compte !

Tous les échanges depuis les nouvelles applications seront pilotés au travers de la plateforme ESB. L’autre grand chantier en parallèle est de migrer les interfaces historiques. Le premier lot regroupera les interfaces réalisées avec SSIS pour l’e-commerce, car il y a une forte mutualisation avec la CRM en termes de nature et d’objets. Notre démarche reste pragmatique : nous avions par exemple démarré les échanges de flux entre l’e-commerce et l’ERP avec SSIS car nous savions que cela serait fonctionnel en attendant le chantier ESB. C’était une première expérience de changement de technologie.

La priorisation du plan de migration des interfaces existantes dépendra ensuite des enjeux technologiques et techniques. Pour certaines applications sous l’ancien mode d’interopérabilité, les « sachants » qui ont développé les interfaces ne sont plus présents. Le risque pour l’exploitation et la criticité seront ainsi des critères de priorisation.

Quels sont les prochains projets et comment la plateforme ESB accompagnera ces évolutions ?

Nous sommes encore en train d’élargir le périmètre applicatif de PAREDES et cela ne va pas s’arrêter. Demain, le groupe grandira encore. C’est dans notre stratégie !

Nous intégrerons de nouveaux logiciels ; nous mettrons à disposition de nos clients des API afin qu’ils récupèrent et transposent automatiquement de l’information dans leurs applications, ou qu’ils opèrent certains processus métiers. Une de nos ambitions est de résoudre un certain nombre des problématiques clients tout en intégrant cette démarche au sein de l’offre de services de Paredes. Ces applications très orientées métiers vont avoir besoin d’interpeller la plateforme, d’envoyer de l’information à une autre, de communiquer avec les SI des clients… Faire communiquer les SI entre eux, cela fait partie des services que vous visons à développer !

La plateforme ESB sera un accélérateur pour tous ces nouveaux projets. Nous l’avons vécu récemment dans le cadre de notre projet de refonte du SI RH. Cela a facilité le travail d’intégration de pouvoir directement mettre en place une approche moderne d’échanges via l’ESB : récupérer les données, les mettre en forme, les transporter dans le SI…

De plus, si cette plateforme est initialement utilisée par le SI de la partie française, la filiale en Italie dispose aussi d’un SI composite. On est une entreprise qui vit et la collaboration ne fera que se renforcer entre la France et l’Italie en termes de savoir ou d’applications communes. La croissance externe fait également partie de notre stratégie : il faut être prêt à assembler des SI ou les faire communiquer.

Le MDM (Master Data Management) sera aussi une suite logique dans notre structuration du SI. Et pour finir, comme nous allons accélérer sur le digital, il y aura de plus en plus de services, et donc de plus en plus d’événements, de temps réel… C’est également pour traiter de l’événementiel que nous avions besoin d’un ESB !

Ce ne sont plus deux personnes ne parlant pas la même langue qui essaient de communiquer ! Chacun s’exprime et il y a un interprète entre les deux.

Avec vos retours d’expérience, quels conseils partageriez-vous à un DSI qui entamerait un projet similaire au vôtre ?

Mon premier conseil, c’est qu’il ne faut pas se précipiter. Les enjeux technologiques sont forts : de mon point de vue, il est indispensable de prendre le temps d’être au clair sur ses besoins, les factualiser, et ensuite choisir une solution vraiment adaptée.

D’autres questions sont à se poser : va-t-on se retrouver avec une solution que des équipes métiers éclairées pourront utiliser ? Est-elle réservée à des profils purement techniques ? L’outil doit être puissant dans la proposition et simple dans la mise en œuvre.

Je préconise aussi d’être pragmatique sur les chantiers à mener : commencer par les choses simples et monter au fur et à mesure en complexité afin de gagner en maîtrise.

Il faut également anticiper les besoins futurs. La solution doit être évolutive. Par exemple, nous sommes de plus en plus interpellés par nos clients autour de l’accès à l’information. Nous ne voulions pas que le portail clients, qui est leur point d’entrée, soit d’une complexité folle. Ce portail devait ainsi s’appuyer sur une logique d’API et de web services. L’ESB devait prendre en compte dès le départ ce contexte afin de participer à délivrer des informations à nos clients de manière très évènementielle.

Ce n’est pas ETL ou ESB mais ETL et ESB ! Il ne faut pas s’imaginer que disposer d’un ESB implique de jeter son ETL. Pour de très grosses volumétries, l’ETL reste plus performant, au contraire l’ESB répondra plus efficacement pour distribuer de l’information sur sollicitation, à tout moment, si une application a enclenché un service. Ce sont deux philosophies différentes.

Au-delà de la solution, penser à comment l’écosystème va pouvoir vous accompagner est également essentiel ! Choisir les bons partenaires est un des premiers gages de réussite. Sur ces outils et ces technologies, le partenaire intégrateur est aussi important que le partenaire éditeur. Nous sommes partis sur un « Why Not », car nous avions confiance dans notre partenaire Data-Major.

Pour prendre comme exemple notre retour d’expérience, nous sommes arrivés au choix de Blueway avec une prise de risque partagée entre Data-Major et nous. Nous étions de part et d’autre convaincus de la philosophie de l’outil. Data-Major s’est investi à nos côtés pour monter en compétences sur la technologie Blueway. Cela faisait partie du deal et cela a rendu les choses beaucoup plus faciles ! Nous n’avions en effet pas suffisamment de temps devant nous pour intégrer les « sachants » dans nos équipes. Cette approche et cette répartition ont permis d’aller vite tout en limitant les risques.

Vis-à-vis de Blueway, l’éditeur, un point que j’apprécie particulièrement et qui remonte en COPIL, c’est que Blueway ne s’est pas contenté de vendre sa licence. Si Data-Major partage les risques du projet avec nous, Blueway s’est aussi engagé à nos côtés pour nous accompagner tous les deux. Dès que l’équipe de Data-Major a eu besoin d’affiner ses connaissances, de monter en expertise, d’aller chercher un expert, Blueway a toujours répondu présent.

Nous sommes tous les trois des entreprises à taille humaine. Le trio fonctionne bien, et rechercher cette synergie est pour moi le conseil le plus important !