L’intégration de données, chantier d'envergure chez VINCI Energies

Une stratégie de croissance continue source de défis pour la DSI

La stratégie d’acquisition externe présentée par Yves Pellemans, CTO d’Axians au MagIT, se vérifie à l’échelle du groupe. Rien qu’en 2021, il a racheté Gillz, Honold GmbH, Kurz Leitungsbau, Megatech, SETRA Conseil, Legendre Conveyors… et l’année n’est pas encore terminée.

En 2020, VINCI Energies accueillait sept nouvelles venues, et huit en 2019. 

De cette politique découle un deuxième challenge pour VESI. « La plupart de ces entreprises sont souvent très autonomes dans leur fonctionnement et leur gestion des activités. Elles ont donc la possibilité de bénéficier des services du groupe, mais aussi d’avoir leurs propres applications spécifiques, de les conserver lorsqu’elles intègrent le groupe tout en respectant nos standards », indique Sébastien Brault lors de son intervention dans le cadre de la conférence MuleSoft Connect 2021. « Nous devons aussi connecter un bon nombre d’outils déployés dans des clouds publics ou privés, sur site, suivant tout un ensemble de modes d’intégration hétéroclite », ajoute-t-il.

Cela demande de connaître les fonctionnements des API et des Webservices de type WSDL, SOAP et REST, en plus de maîtriser des langages et frameworks comme JAVA, J2EE, XML ou encore XSLT.

Et, bien évidemment, en sus de ce juste équilibre à trouver, VINCI Energies SI doit « supporter les activités des entreprises du groupe, à travers les applicatifs de gestion », mais aussi couvrir les nouveaux usages liés au sujet de l’IoT et du Smart Building, entre autres.

À cela s’ajoutent des défis purement informatiques. Pour le responsable de l’intégration de données au sein de VESI, il s’agit d’adopter une plateforme unique pour supporter les traitements en temps réel et batch. Cette plateforme doit, à terme, remplacer un ESB et un ETL existants, à savoir Oracle SOA Suite et SAP Data Services. « Cela permettra de favoriser davantage d’échanges de données en temps réel et nous allons essayer d’éliminer au maximum les traitements batch asynchrones », anticipe Sébastien Brault. La promesse d’un tel chantier au long cours est également de rationaliser les compétences. « Nous avons deux unités techniques au sein de la même équipe. Ce n’est pas forcément simple de communiquer ni de transférer les compétences. Nous voulons adopter un langage commun ».

Outre un gain d’efficacité de l’équipe intégration, un tel projet implique l’optimisation des coûts de maintenance et de run.

« On nous demande d’aller toujours plus vite, nous avons beaucoup de projets d’intégrations de données ».

Cette refonte découle également des demandes des clients internes. « On nous demande d’aller toujours plus vite, nous avons beaucoup de projets d’intégrations de données », témoigne le responsable. Il faut accélérer les livraisons, donc diminuer les temps de développement et pour cela rationaliser les méthodes, ce qui passe par la réutilisation des composants.

Un bon nombre d’éditeurs se positionnent sur ce marché de l’intégration et assurent répondre à tous ces critères.

Ce projet a émergé en 2019. Après une période d’étude du marché et de sélection en 2020, VINCI Energies SI a fait le choix de la plateforme iPaaS MuleSoft Anypoint parce qu’elle promettait de répondre aux trois défis organisationnels cités plus haut. « Nous avons estimé que la plateforme de MuleSoft pouvait couvrir tous nos cas d’usage métier », affirme Sébastien Brault. « Nous avons également jugé que le module API Management est suffisamment mature et performant pour couvrir nos besoins de gouvernance et de sécurisation de l’accès aux données », complète-t-il.

Aussi, un PoC a permis de rassurer VESI quant aux performances de MuleSoft Anypoint au regard des traitements batch. L’éditeur et la société ont créé un flux de SAP ECC vers S/4HANA pour un cas d’usage BI consacré à l’analyse de factures. Ce flux ETL à base de Web Services et comprenant plusieurs transformations de données (tri, conversions, etc.) a permis de traiter 13 millions de factures en 56 minutes, selon le responsable et ses accompagnateurs chez MuleSoft.

S’approprier le modèle API-led de MuleSoft

Le projet global de mise en œuvre a réellement démarré au début de l’année 2021, avec le soutien de Capgemini, un partenaire de l’éditeur.

Au vu de l’organisation particulière de VINCI Energies, il faut bien évidemment s’attendre à une multiplication des projets liés à l’iPaaS. Pourtant, il était important de planifier ce chantier et de s’atteler aux phases les plus importantes, selon les dires du responsable.

Lui et les équipes assignées ont d’abord décidé de s’occuper de la migration de l’existant, puis de développer en parallèle deux cas d’usage. « Ce sont les trois programmes principaux, mais il y en a d’autres en préparation », avance-t-il.

Sans surprise, la migration de l’existant est « le projet majeur, un passage obligé ». « Nous avons environ 450 interfaces à migrer tout en supportant les nouvelles intégrations. L’idée, c’est de migrer ces interfaces intelligemment tout en offrant un catalogue de services disponibles à la demande pour nos clients internes », explique Sébastien Brault.

« Pour ce faire, nous allons modéliser tout le SI, toutes les entités commerciales et les microservices associés. Nous voulons offrir de nouveaux services au travers d’un catalogue d’API. Le but est de permettre à nos entreprises d’accéder aux données centralisées de manière plus autonomes, ce qui demande de bâtir un point d’accès unifié et sécurisé », ajoute-t-il.

Cela passe par une formation des équipes techniques chargées de l’intégration. « Nous avons “mis le paquet” sur la formation avant de lancer la phase de développement », affirme le responsable. Il fallait les familiariser aux outils de l’éditeur, mais aussi, et surtout à l’architecture « API-led », une approche spécifique à MuleSoft.

Cette architecture est divisée en trois couches d’API. La première, « System APIs » vise à se connecter aux systèmes sous-jacents, certaines bases de données ou encore des ERP. La couche « Process APIs » se place un cran au-dessus pour interagir avec les données et les « façonner » au sein d’un système unique ou entre plusieurs systèmes. La troisième couche nommée « Experience APIs » vise à tirer des flux entre les bases de données ou les entrepôts communs vers des applications métiers. Les interfaces de cette troisième strate n’accèdent pas à toutes les données : des règles définissent leur comportement d’accès et d’authentification.

Lors de sa présentation, Sébastien Brault donne l’exemple d’une interface pour le flux « affaire ». « Chez VINCI Energies, un chantier ou une affaire peut être enregistré par le biais de deux ERP : soit SAP, soit Navision. L’on récupère ces informations par des system APIs. Une Process API agrège ces deux sources de données (depuis les API dédiées à SAP et Navision) que l’on redistribue ensuite aux différentes applications du groupe qui consomment des affaires via les Experience API. Ici, j’en matérialise deux pour l’exemple : cela peut être dans une application mobile ou un CRM. À terme, ce seront une trentaine de systèmes qui accéderont à ces données au travers d’Experience APIs », illustre le responsable.

Le deuxième projet, lui aussi lancé en 2021, vise à bâtir un outil de Field Service Management pour VINCI Facilities. Cette branche dédiée à la maintenance, aux services aux habitants et aux mesures des performances des bâtiments souhaite fluidifier les interventions de son personnel et l’intégration de nouveaux clients, avec pour objectif final d’augmenter leur satisfaction.

« Le projet consiste à mettre en place une plateforme qui permettra de suivre l’activité des entreprises, mais aussi d’interagir directement avec ses clients. Par exemple, elle offrira la possibilité d’effectuer des demandes d’intervention, ce qui passera par une plateforme Web, des applications mobiles et un back-end », détaille Sébastien Brault. L’échange de données se fera par le biais de MuleSoft pour rendre la plateforme accessible à 200 clients.

Enfin, VINCI Energies SI participe au développement d’une application SIRH à l’échelle du groupe. Elle vise à suivre les carrières, les formations, les évaluations et à unifier les outils de paie. « Nous avons à peu de chose près un outil de paie différent par pays où nous sommes présents », indique le responsable, conscient de l’envergure de la tâche.

Pour chacun de ses projets, VESI s’appuie sur l’architecture illustrée ci-dessus et ajoute ou ajuste des Experience API en fonction du cas d’usage.

Une rationalisation des coûts pour supporter davantage de projets

« Nous avions des interfaces point à point. Ce que l’on espère, c’est une réutilisabilité ainsi qu’une standardisation des échanges et des interfaces via MuleSoft », répète le responsable. Ici, point de duplication. Les API qui peuvent être réutilisés le sont pour éviter des coûts supplémentaires de maintenance. C’est particulièrement vrai pour la Process API, commune aux trois projets présentés par la DSI.

« Nous avions des interfaces point à point. Ce que l’on espère, c’est une réutilisabilité ainsi qu’une standardisation des échanges et des interfaces via MuleSoft ».

Tous les objets, les politiques d’accès, de sécurité et les API définis sous la responsabilité de Sébastien Brault sont inventoriés au sein de MuleSoft Exchange.

Reste à savoir comment ces API sont et seront déployées. Comme la majorité des entreprises, les environnements du SI de VINCI Energies sont composites : les applications sont déployées on-premise, dans des instances de cloud privé ou de cloud public. Historiquement, MuleSoft Anypoint, propose Runtime Fabric, un moyen technique pour déployer les API sur site ou dans le cloud, plus spécifiquement sur des serveurs bare-metal, des machines virtuelles ou sur les instances Kubernetes des fournisseurs de cloud (EKS, AKS, GKE). À cela s’ajoute CloudHub, une offre managée pour héberger les interfaces de programmation dans le cloud. VINCI Energies SI a choisi d’employer les deux méthodes. Pour l’instant, Runtime Fabric est le type d’environnement le plus utilisé on-premise.

« Une étude a été menée en amont du projet avec l’équipe MuleSoft. Même si ce n’est pas forcément simple d’estimer cela, nous escomptons environ 25 à 30 % de gains financiers par rapport à l’ancienne architecture », anticipe Sébastien Brault.

« Nous espérons surtout apporter une valeur supplémentaire en matière d’intégration de données à nos entreprises. Ça ne se mesure pas », tranche-t-il.

En clair, il ne s’agit pas de faire la chasse aux économies, mais « de rationaliser les coûts, car cette plateforme unifiée doit permettre de supporter davantage de projets et de cas d’usage métier ». « Nous n’avons pas encore évalué tous les résultats, le projet est en cours », rappelle le Data Integration Manager.

Deux ans pour migrer 450 interfaces d’intégration

Il reste donc un long chemin à parcourir avant de potentiellement tirer les fruits d’une telle plateforme.

« Nous nous attelons à migrer l’existant “tel quel”, sinon nous ne nous en sortirons pas à temps », déclare Sébastien Brault. « Nous migrons [les interfaces] entité commerciale par entité commerciale. En parallèle, nous avons une réflexion pour standardiser l’urbanisation de nos interfaces sur le long cours. Pour autant, nous nous donnons la possibilité de revenir sur ce qui est déployé au besoin », ajoute-t-il.

« Nous nous attelons à migrer l’existant “tel quel”, sinon nous ne nous en sortirons pas à temps ».

Basés au Mans, les développeurs et ingénieurs de VINCI Energies travaillent selon des approches agiles et DevOps au rythme de sprints. Ils sont épaulés par des consultants techniques en provenance de Capgemini et MuleSoft.

« Une équipe centrale nommée Design Autorithy est là pour mettre en place les grandes briques de la solution, faire respecter les standards et assurer la cohérence technique. Ensuite, quatre équipes de développement assurent la migration et la réalisation », témoigne Sébastien Brault.

Au total, une douzaine de développeurs sont formés à MuleSoft. Chaque équipe est dirigée par un chef de projet et des tech leads encadrent les programmeurs. Des analystes fonctionnelles, des architectes solutions et entreprises ainsi que des managers complètent le cœur de cette « task force ». Dans une offre d’emploi publié au début du mois de juillet, VESI précisait que l’équipe dédiée à l’intégration de données compte 25 personnes.

En mai dernier, le responsable indiquait que la mise en production de la plateforme d’intégration démarrerait en juillet 2021. VESI prévoit de finaliser la migration dans les deux ans et poursuivre les projets par le biais de la réutilisation des API accumulées au fil du temps.