CLS Group : Le Machine Learning pour améliorer les capacités de traitement de l’analyse d’images à haute résolution

Temps de lecture : 7 minutes

CLS Group (Collecte Localisation Satellites) est un groupe mondial, spécialisé dans le développement de solutions spatiales dédiées à l’étude, la protection de notre planète et à la gestion durable de ses ressources. 

CLS intervient dans des domaines d’activités comme la gestion durable des pêches, la sécurité maritime, la surveillance environnementale, la mobilité, les énergies et les infrastructures. Afin d’améliorer les capacités de traitement de son activité d’analyse d’images à haute résolution, l’entreprise a développé une plateforme de Machine Learning basée sur une infrastructure Cloud AWS et sur Kubeflow.

Nicolas Renard (Datalead manager) & Philippe Roques (Directeur Général Adjoint), répondent à nos questions sur ce projet mené en collaboration avec les équipes de Devoteam Revolve.

A quel besoin répond la plateforme Data/ML Ops ?

Nous faisons de l’analyse d’image à haute résolution (images satellite, prise de vues aériennes), afin de produire des plans d’occupation des sols. Jusque-là, ces processus d’analyse étaient manuels : les photo-interprètes chargés de l’analyse détourent des polygones de zones homogènes, comme du bâti, de la forêt, ou du végétal. Pour répondre aux besoins de nos clients, nous travaillons sur des images à la résolution de plus en plus fine. Le nombre de pixels augmente, et en conséquence le détourage doit se faire sur des polygones de plus petite taille. Le détourage est beaucoup plus fin, on rentre dans le détail de chacune des parcelles. Cela nous posait un problème de passage à l’échelle, pour couvrir des dizaines de milliers de km 2 de terrain, nous aurions dû faire intervenir des équipes beaucoup plus grandes, ce qui n’était pas viable d’un point de vue opérationnel. 

Nous avons donc étudié une solution de Machine Learning, où les données passées seraient utilisées pour entraîner des modèles à proposer des classifications et des segmentations. Ce proof of concept devait nous permettre de vérifier que les résultats fournis par l’algorithme étaient satisfaisants pour les photo interprètes, et leur permettent d’analyser non pas des pixels isolés, mais des polygones pré calculés par l’algorithme.

Une fois que nous étions convaincus, comment industrialiser ce processus ? Au vu de la diversité des paysages à traiter, nous ne pouvions pas avoir un modèle unique pour l’ensemble de nos territoires. Nous avions donc besoin d’un processus itératif, permettant de profiter de la photo interprétation à sur un jour J pour entraîner le modèle opérant à j+1. C’est-à-dire un système autonome capable d’entraîner les modèles, de produire un résultat le lendemain, puis de les ré-entraîner avec les résultats validés par les photo interprètes.

Ce nouveau processus, en facilitant le travail des photo-interprètes, apporte un gain de temps énorme : on couvre jusqu’à 4 fois plus de zones sur une journée, ce qui est suffisant pour répondre à la croissance des besoins de nos clients

Quels étaient les principaux challenges de ce projet ?

En premier lieu, la qualité de l’algorithme, dont nous devions nous assurer qu’il fournisse des résultats de qualité pour les photos interprètes.

En second lieu, faire intervenir un Data Scientist à chaque étape de ré-entraînement aurait alourdi le processus. Il nous fallait donc l’automatiser, grâce à la mesure des courbes d’apprentissage et au ML Ops.

Enfin le passage à l’échelle, c’est-à-dire développer une capacité de traitement des images en batchs indépendants (en découpant une image en images plus petites). Pour ce point, nous avons choisi de traiter les images avec un algorithme hébergé sur un cluster Kubernetes, capable de paralléliser ces jobs de traitement. 

Quel environnement technologique avez-vous choisi pour cette plateforme ?

Nous avons été bien accompagnés par Devoteam Revolve sur ce sujet. Le projet a démarré sur une feuille blanche, et même si nous avions quelques idées en tête sur les solutions possibles, je voulais que l’accompagnement puisse apporter une réflexion sur les différentes options possibles. Nous n’avions pas vraiment de spécifications précises, mais plutôt un recueil de user stories que nous avons soumis à l’équipe Devoteam Revolve.

Nos seuls pré-requis étaient que la solution soit dans le Cloud, et plutôt sur AWS, et de recourir autant que possible à des services managés pour parvenir rapidement à l’objectif, et pallier notre manque de connaissances en interne sur le Cloud. Enfin, la solution devait répondre autant à nos besoins de performance métier que de scalabilité. Nous avons discuté lors des premiers échanges avec l’équipe Devoteam Revolve de la possibilité d’utiliser Kubernetes, en interne on utilisait déjà ML Flow et des clusters Kubernetes.

Devoteam Revolve nous a conseillé Kubeflow, un bon moyen pour orchestrer les pilotes de Machine Learning, tout en laissant la possibilité d’utiliser des ressources qu’elles soient dans le Cloud ou non. Kubeflow comme wrapper universel nous assurait un environnement agnostique de la plateforme.

La solution retenue fonctionne comme suit : l’image et les données de photo interprétation sont envoyées vers un bucket Amazon S3; une fonction Lambda lance ensuite le pipeline Kubeflow d’entraînement des modèles. Il est ensuite publié dans un model registry, et suite à la création du modèle, un processus d’inférence est lancé dès qu’une nouvelle image est disponible. Le résultat de classification est poussé dans S3, et l’utilisateur est ensuite notifié pour qu’il puisse le récupérer. La prochaine étape sera d’exposer une API.

Cette solution utilise donc Kubeflow, Lambda, un cluster Kubernetes managés EKS, Amazon S3, et le service d’authentification Cognito. Dans l’optique d’avancer rapidement, nous avons aussi tiré parti d’Amazon Sagemaker pour l’orchestration, en attendant de développer une solution maison.

Comment les services AWS ont-ils répondu à ce besoin de scalabilité et de rapidité ?

L’utilisation de services managés nous a évité d’instancier un cluster Kubernetes sur notre environnement on premise, et de devoir acheter du GPU en conséquence. C’est une petite révolution pour nous de passer du modèle Capex vers l’Opex, mais cela nous a permis d’avoir immédiatement un cluster à disposition, quand cela nous aurait pris des mois pour acheter le matériel, le configurer, sans compter la mobilisation des équipes. Utiliser une solution managée AWS nous a donc fait gagner beaucoup de temps sur la disponibilité et la configuration du Cluster.

Sur la partie Kubeflow, nous nous sommes appuyés sur les compétences de l’équipe Devoteam Revolve pour la construction et la configuration du pipeline. Au final, les facteurs clés de succès de ce projet ont été la mise à disposition de services managés, et l’accompagnement de Devoteam Revolve qui nous a permis d’acquérir rapidement les connaissances qui nous manquaient sur les services Cloud.

Quelle a été la plus value de l’accompagnement de Devoteam Revolve ?

Nous avions en interne la compétence pour comprendre le fonctionnement de Kubeflow, mais la valeur ajoutée de l’accompagnement de Devoteam Revolve est dans sa capacité à intégrer les différents services. Cela nous a beaucoup apporté, et nous avons pu réaliser en 6 mois un projet qui par ailleurs nous aurait pris le triple en interne.

Capitaliser sur l’expérience de Devoteam Revolve nous a fait gagner du temps sur des sujets sur lesquels nous n’avons pas de valeur ajoutée. Il nous a semblé plus important que nos développeurs se concentrent sur leurs compétences autour du ML Ops et CI/CD, bref déployer des choses qui ont du sens point de vue métier, sans avoir à se concentrer aussi sur la partie infrastructure IT.

Où en est le projet aujourd’hui ?

A quelques jours près, nous sommes dans les délais de livraison, ce qui est suffisamment rare pour être signalé sur un projet de cette envergure. L’accompagnement de Devoteam Revolve sur les problématiques ML Ops a également porté ses fruits, et nous sommes actuellement dans la phase de formation et de capitalisation pour que les équipes prennent en main ce qui a été livré.

Les équipes pourront ensuite développer de nouveaux algorithmes sur cette plateforme. Jusque-là, nous faisions de la classification des sols, mais nous voudrions proposer de nouveaux services comme la détection de changement, le traitement d’imagerie radar, de séries temporelles, de données de trajectoire, etc. L’infrastructure mise à disposition va nous permettre de développer d’autres cas d’usage.

Pour conclure, nous sommes vraiment ravis de cet accompagnement, dans lequel nous avons trouvé non pas une relation client fournisseur, mais une relation de partenariat. L’organisation mise en place a bien fonctionné, avec des petites équipes agiles, bien intégrées, qui collait parfaitement à notre besoin de montée en compétence. Il y a aussi une souplesse, une adaptabilité qu’on voit rarement chez les prestataires, car initialement le projet n’était pas réellement spécifiable, et donc ne nous rendait pas éligible à un forfait. Nous avons pu travailler avec Devoteam Revolve sur des cycles itératifs assez courts, sur lesquels nous pouvions faire évoluer les choix techniques.

En termes de réussite du projet, c’est vraiment un point à souligner, avoir une boucle de rétroaction courte nous a vraiment permis d’avancer de concert. Les deux parties étaient moteur, au-delà de la relation contractuelle. Nous avons même intégré l’équipe Devoteam Revolve dans la recherche utilisateur avec nos équipes à Lille, pour les mettre au contact du besoin utilisateur. Comprendre le métier, comprendre les enjeux de la photo interprétation était déterminant pour la réussite fonctionnelle du projet, et son appropriation par nos équipes.

Commentaires :

A lire également sur le sujet :