MLOps avec Microservices : Une Étude de Cas dans le Domaine Maritime

Informations Fondamentales

• ID de l'article : 2506.06202
• Titre : MLOps with Microservices: A Case Study on the Maritime Domain
• Auteurs : Renato Cordeiro Ferreira, Rowanne Trapmann, Willem-Jan van den Heuvel
• Institutions : Jheronimus Academy of Data Science (JADS), Eindhoven University of Technology (TUe), Tilburg University (TiU)
• Classification : cs.SE cs.AI cs.LG
• Date de publication : arXiv:2506.06202v2 cs.SE 11 août 2025
• Lien de l'article : https://arxiv.org/abs/2506.06202

Résumé

Cette étude de cas décrit les défis et les enseignements tirés de la construction du système Ocean Guard : un système habilitant l'apprentissage automatique (MLES) pour la détection d'anomalies dans le domaine maritime. L'article présente d'abord les spécifications et l'architecture du système. Ocean Guard adopte une conception architecturale en microservices, permettant à plusieurs équipes de travailler en parallèle. Il discute ensuite de la manière dont les développeurs ont adapté la conception basée sur les contrats à MLOps pour réaliser cet objectif. En tant que MLES, Ocean Guard adopte des contrats de code, de modèle et de données pour établir des principes directeurs entre les services.

Contexte et Motivation de la Recherche

Contexte du Problème

1. Accélération de la transformation numérique maritime : Selon l'Organisation maritime internationale (OMI), les navires modernes sont devenus des « centres de données flottants », équipés de centaines de capteurs générant d'énormes volumes de données hétérogènes
2. Environnement opérationnel complexe : Le domaine maritime se caractérise par un mouvement continu transfrontalier, des cadres réglementaires diversifiés et une vulnérabilité aux conditions météorologiques
3. Défis du traitement des données : Nécessité de systèmes capables d'ingérer, traiter et analyser à grande échelle différents flux de données, tout en maintenant la fiabilité opérationnelle dans un environnement à connectivité et conditions changeantes rapidement

Motivation de la Recherche

1. Besoin de convergence technologique : Combiner les meilleures pratiques MLOps avec l'architecture en microservices pour répondre aux besoins d'analyse prédictive, de détection d'anomalies et d'optimisation des trajets du domaine maritime
2. Collaboration multidisciplinaire : Nécessité de soutenir le développement parallèle d'équipes multidisciplinaires incluant ingénieurs logiciels, scientifiques des données et ingénieurs en apprentissage automatique
3. Scalabilité du système : L'architecture en microservices est particulièrement adaptée aux exigences de modularité, d'extensibilité et de résilience du domaine maritime

Contributions Principales

1. Proposition d'une approche de conception pilotée par les contrats applicable aux MLES : Extension du concept de contrats de code des microservices aux contrats de données et de modèles
2. Construction d'une architecture complète de système de détection d'anomalies maritime : Système Ocean Guard basé sur les microservices, soutenant le développement parallèle multidisciplinaire
3. Validation de l'application de la conception pilotée par le domaine (DDD) dans MLOps : Création d'un langage unifié par la conception pilotée par le domaine, améliorant la communication entre équipes multidisciplinaires
4. Fourniture d'expérience pratique en développement MLES : Identification et résolution de trois défis majeurs : le couplage, l'alignement et la communication

Détails de la Méthodologie

Spécifications du Système

Exigences Fonctionnelles

Fonctionnalités de l'Enquêteur (Investigator) :

• I1-I6 : Affichage géographique, filtrage, identification du type d'objet, récupération multi-sources, visualisation des métadonnées, suivi des trajectoires
• I7-I9 : Mise en évidence des anomalies, filtrage des anomalies, visualisation des explications d'anomalies

Fonctionnalités du Détecteur d'Anomalies (Anomaly Detector) :

• A1-A3 : Détection d'anomalies, énumération des anomalies, explication des anomalies

Exigences Non-Fonctionnelles

1. Interprétabilité : Utilisation de modèles interprétables ou de techniques d'explication de boîte noire (SHAP, LIME)
2. Compatibilité : Conformité aux normes de l'UE, soutien d'une intégration rapide avec d'autres systèmes
3. Résilience : Traitement de sources de données à haut volume et haute vélocité
4. Conformité : Respect des réglementations européennes telles que le RGPD et la Loi sur l'IA

Architecture du Système

Conception des Cinq Sous-systèmes

1. Acquisition de Données (Data Acquisition)
   • Fournisseurs tiers (1), capteurs physiques (2), web scrapers (3)
   • Stockage des étiquettes (A) et stockage des données brutes (B)
2. Entraînement Continu (Continuous Training)
   • Pipeline de génération de données synthétiques (I), pipeline d'augmentation de données (II)
   • Pipeline d'entraînement basé sur des règles (III), pipeline d'entraînement basé sur ML (IV)
   • Stockage des métadonnées (F) et registre de modèles (G)
3. Service (Serving)
   • Pipeline de prédiction par lot (VIII) et service de prédiction API (8)
   • Stockage des prédictions (H)
4. Surveillance (Monitoring)
   • Application de gouvernance (7) et stockage de télémétrie (I)
5. Livraison Continue (Continuous Delivery)
   • Pipeline CI (V), pipeline CD (VI), pipeline CD4ML (VII)
   • Registre d'artefacts (D)

Conception de l'Architecture API

Adoption de l'Architecture Hexagonale :

1. Noyau (Core) : Implémentation de la logique métier, conformité au modèle DDD
   • Entités (Entities), objets de valeur (Value Objects)
   • Agrégats (Aggregates), services (Services)
2. Ports (Ports) : Établissement de contrats entre le noyau et les adaptateurs
   • Référentiels de base de données, injection de dépendances, mécanismes de sécurité, routeurs web
3. Adaptateurs (Adapters) : Communication avec les dépendances externes
   • Adaptateurs d'entrée : modèles, API tiers, stockage, base de données, configuration
   • Adaptateurs de sortie : web, cache

Configuration des Équipes et Flux de Travail

Points d'Innovation Technique

Développement Piloté par les Contrats (Contract-Based Development)

1. Contrats de Code (Code Contracts)

• Définition : Documentation du comportement d'interaction synchrone/asynchrone entre deux services via le protocole HTTP
• Scénarios d'application :
  • Contrat entre web scraper et sources de données externes
  • Contrat entre service de prédiction API et application web

2. Contrats de Données (Data Contracts)

• Définition : Documentation du format attendu dans les stockages de données, incluant types, formats, distributions et protocoles de lecture/écriture
• Scénarios d'application :
  • Contrat entre producteur et consommateur de stockage d'étiquettes
  • Contrats multi-parties du stockage de données brutes
  • Contrats entre pipelines de données traitées

3. Contrats de Modèles (Model Contracts)

• Définition : Documentation des entrées/sorties attendues du modèle et du format de stockage
• Scénarios d'application : Contrat entre pipelines d'entraînement et services de prédiction dans le registre de modèles

Langage Unifié (Ubiquitous Language)

Création d'un vocabulaire partagé entre équipes via DDD, améliorant :

• La compréhension entre parties prenantes et développeurs
• L'alignement entre équipes
• L'explication des concepts de données et de modèles

Configuration Expérimentale

Environnement de Développement

• Référentiel de Code : Gestion centralisée du contrôle de source
• Outils de Développement : IDE (4) pour l'ingénierie logicielle structurée, Notebooks (5) pour le prototypage interactif et l'analyse
• CI/CD : Pipeline d'intégration continue, pipeline de livraison continue, pipeline de livraison continue ML

Architecture de Déploiement

• Conteneurisation : Utilisation du registre d'artefacts pour gérer les composants logiciels versionnés
• Service de Planification : Coordination de l'exécution des composants
• Système de Surveillance : Application de gouvernance surveillant l'utilisation des modèles et du système

Défis et Solutions

Trois Défis Majeurs

1. Couplage (Coupling)
   • Problème : La complexité du système rend les modifications de composants susceptibles d'avoir des effets en cascade
   • Solution : Réduction des problèmes d'intégration par la conception pilotée par les contrats
2. Alignement (Alignment)
   • Problème : Défis de coordination du travail parallèle de quatre équipes professionnelles
   • Solution : Définition claire des limites, intégration des pipelines CI/CD
3. Communication (Communication)
   • Problème : Difficulté à expliquer l'évolution du système à des parties prenantes de différents horizons techniques
   • Solution : Établissement d'un langage unifié via DDD

Efficacité des Solutions

Travaux Connexes

Développement du Domaine MLOps

• À partir de 2022 : Proposition de plusieurs architectures de référence MLES
• SE4AI : Domaine émergent d'adaptation des techniques d'ingénierie logicielle à la création de systèmes IA
• Componentisation du système : Les MLES sont décrits comme comprenant plusieurs composants distribuables entre services

Architecture en Microservices

• À partir de 2015 : Émergence du style architectural en microservices, résolvant les défis de modularité, d'extensibilité et de résilience
• Applicabilité maritime : Composants spécialisés traitant différentes sources de données maritimes et besoins analytiques

Conclusion et Discussion

Conclusions Principales

1. Validité de l'architecture : L'architecture en microservices a soutenu avec succès le développement parallèle multidisciplinaire du MLES
2. Extension des contrats : Extension réussie du concept de contrats de code des microservices aux dimensions de données et de modèles
3. Applicabilité de DDD : La conception pilotée par le domaine a efficacement amélioré la communication et la coordination entre équipes multidisciplinaires
4. Réponse aux défis : La conception pilotée par les contrats et le langage unifié ont efficacement résolu les défis de couplage, d'alignement et de communication

Limitations

1. Restrictions de Sensibilité : En raison de la sensibilité du projet, l'article n'aborde pas les modèles de données spécifiques et les techniques de détection d'anomalies
2. Contraintes Académiques : Les équipes de recherche et d'innovation sont composées d'étudiants, soumis aux délais académiques
3. Phase d'Implémentation : Le système est toujours en développement, manquant de validation à long terme en environnement de production

Orientations Futures

1. Perfectionnement Fonctionnel : Développement continu pour satisfaire tous les besoins fonctionnels et non-fonctionnels
2. Exploration Technologique : Poursuite de l'exploration des technologies de pointe et pratiques avec les équipes de recherche et d'innovation
3. Évolution de l'Architecture : Évolution basée sur l'approche contractuelle établie et le langage unifié guidant le processus de développement

Évaluation Approfondie

Avantages

1. Valeur Pratique Élevée : Fourniture d'une étude de cas complète sur la combinaison de MLOps et des microservices
2. Innovation Méthodologique : Extension originale de la conception pilotée par les contrats aux dimensions de données et de modèles
3. Architecture Complète : Conception architecturale du système complète, couvrant tous les aspects du MLES
4. Collaboration d'Équipe : Résolution réussie des défis du développement parallèle multidisciplinaire
5. Orientation Pratique : Fourniture d'expérience et d'enseignements transférables pour des projets similaires

Insuffisances

1. Profondeur Technique Limitée : Manque de détails spécifiques sur les algorithmes ML et le traitement des données en raison des restrictions de sensibilité
2. Évaluation Insuffisante : Absence d'évaluation quantitative des performances du système, de l'extensibilité, etc.
3. Absence de Validation à Long Terme : Le système n'a pas fonctionné longtemps en environnement de production pour validation
4. Analyse Comparative Insuffisante : Manque de comparaison avec d'autres solutions architecturales MLES

Impact

1. Contribution au Domaine : Fourniture d'une référence pratique importante pour la combinaison de MLOps et des microservices
2. Valeur Méthodologique : Extension de la conception pilotée par les contrats avec large applicabilité
3. Pratique d'Ingénierie : Fourniture de modèles efficaces pour la collaboration d'équipes dans les MLES complexes
4. Reproductibilité : Conception architecturale et méthodologie avec bonne reproductibilité

Scénarios d'Application

1. Développement MLES Multidisciplinaire : Systèmes d'apprentissage automatique nécessitant le développement parallèle de plusieurs équipes professionnelles
2. Traitement de Données Complexes : Conception architecturale de systèmes impliquant des données hétérogènes multi-sources
3. Exigences de Conformité Élevée : Applications sectorielles nécessitant le respect de réglementations strictes
4. Systèmes Extensibles : Architecture de systèmes ML hautement modulaires et extensibles

Références

L'article cite 17 références importantes couvrant :

• Recherches sur la transformation numérique maritime
• Meilleures pratiques en architecture en microservices et MLOps
• Méthodologies d'ingénierie logicielle (DDD, architecture hexagonale)
• Ingénierie de systèmes d'apprentissage automatique (SE4AI)

Résumé : Par l'étude de cas Ocean Guard, cet article démontre avec succès l'application de l'architecture en microservices dans MLOps, en particulier la valeur de la conception pilotée par les contrats dans la collaboration multidisciplinaire. Bien que limitée par les restrictions de sensibilité quant aux détails techniques, sa contribution méthodologique et sa valeur d'orientation pratique sont significatives, fournissant une expérience architecturale et de collaboration d'équipe précieuse pour des projets MLES complexes similaires.