Le Machine Learning est sur l’agenda de tous les départements de l’entreprise. S’il est une priorité pour plus de 60% des départements Marketing et Vente, il est tout aussi critique pour la Business Intelligence, la R&D, ou la DSI (étude Forbes 2019). Pour faire le point sur le sujet, nous avons sollicité Julien Simon, évangéliste IA&ML chez AWS : quels sont les cas d’usage ? Comment démarrer un projet de Machine Learning ? Quelles sont les bonnes pratiques, et comment améliorer le modèle, passer à l’échelle et capitaliser ?

Julien Simon est Global Technical Evangelist, Artificial Intelligence & Machine Learning chez AWS. Au quotidien, il accompagne les développeurs et les entreprises à concrétiser leurs projets sur AWS. Entre deux avions, il trouve aussi le temps d’animer un blog et un podcast sur le Machine Learning et l’intelligence artificielle.

Quelles entreprises adoptent le Machine Learning ?

On constate une adoption dans tous les secteurs et dans tous les types d’entreprise. Il n’y a pas d’entreprise type : tous les secteurs d’activité génèrent de la donnée. La distribution, l’industrie, le secteur financier, les services… toutes les entreprises ont des data issues de sites web, d’applications mobiles, de bases de données internes, d’informations partenaires, etc. La donnée est la matière première pour le machine learning, donc les opportunités sont là, y compris dans les secteurs les plus traditionnels, comme l’industrie, qui exploite des données issues de capteurs, de machines, etc.

Quels sont les principaux usages ? 

Historiquement certains acteurs ont attaqué le sujet très tôt. Dans la finance, par exemple, la data et la prédiction ont toujours été au coeur de l’activité. Sur ces secteurs, le cas d’usage est très clair, avec un ROI immédiat si on arrive à prédire correctement. L’e-commerce, avec toutes ses données issues du web et du mobile, a aussi tiré le sujet, mais on assiste aujourd’hui à une généralisation à tous les secteurs. Les cas d’usages sont parfois simples mais sont utiles à l’entreprise, qui peut ainsi prédire ses besoins en approvisionnement ou des métriques opérationnelles. Toutes les entreprises ont des tableaux de bord sur lesquels obtenir des prédictions serait utile. Toutes ces activités de planification peuvent être optimisées par le Machine Learning.

Est-ce que les cas d’usages concernant la DSI se développent également ? 

Une DSI génère des nombreuses données, donc c’est un bon terrain pour le machine learning. Par exemple, le monitoring d’une plateforme, même de petite taille, peut très vite produire plusieurs téraoctets de données quand on agrège tous les logs. Si on s’en tient à la méthode traditionnelle, le monitoring est réactif : des agents extraient des métriques, et on définit des seuils pour déclencher des alertes. Parfois il y a un délai entre l’incident et l’alerte, dû au temps d’acquisition de la donnée, et dans ce cas l’alerte arrive trop tard : l’application ou le site sont déjà down.

Des solutions de machine learning, si elles ne peuvent pas empêcher un incident, peuvent analyser des tendances et détecter des problèmes potentiels, comme une montée en charge, avant qu’ils ne surviennent. On passe alors d’un monitoring réactif à un monitoring prédictif. La sécurité est aussi un bon sujet pour le machine learning : beaucoup d’attaques sont précédées d’une phase de reconnaissance qui peut être détectée grâce au machine learning. Certaines tendances dans les tentatives de connexion peuvent indiquer une attaque en préparation. Ces tendances doivent être investiguées par les équipes, pour déterminer s’il s’agit d’un problème de configuration de la plateforme, ou les prémisses d’une intrusion.

Certaines de ces fonctions ont été intégrées dans les services AWS : les clients peuvent activer l’Auto Scaling prédictif d’Amazon EC2, avec un modèle qui observe le trafic de la plateforme, le modélise, et démarre et arrête des instances automatiquement pour adapter la capacité à la charge. Sur la sécurité, Amazon GuardDuty inspecte automatiquement le trafic réseau pour détecter les activités suspicieuses, et identifier des profils d’attaques un peu complexes.

Une DSI a beaucoup de données, et beaucoup de process manuels, et après un incident de capacité, de monitoring, de sécurité on se rend souvent compte que le problème était souvent visible bien avant. Il y avait des signaux faibles, des débuts de tendance, noyés dans des milliers d’autres données. Ces signaux peuvent être identifiés et interprétés par le Machine Learning.

Quels sont les projets de ML les plus faciles à démarrer et quelles sont les étapes ?

Le premier point sur lequel on n’insistera jamais assez, c’est de déterminer la question à laquelle on veut répondre. Avoir un cas d’usage, vouloir prédire telle métrique, ce n’est pas suffisant. Un projet de machine learning doit avoir pour objectif de répondre à une question aussi précise que “quelle est la marge de l’entreprise le mois prochain avec un intervalle d’erreur de 5% ?”.

La définition du problème est un prérequis à la réussite d’un projet de machine learning. Se lancer sans idée précise du besoin, ou « pour voir ce dont la technologie est capable », c’est une garantie d’échec. On sait ce dont est capable la technologie, des milliers d’entreprises ont des modèles en production qui résolvent des problèmes complexes. 

Quelle est l’étape suivante ?

Une fois qu’on sait à quelle question on veut répondre, il faut cadrer le problème, et voir si la data peut y répondre : est-ce qu’un expert du domaine pourrait consulter des données et en tirer une décision ? Dans ce cas, oui, le machine learning peut aider, et ce traitement peut être automatisé et modélisé. Ensuite, il faut déterminer de quelles données on a besoin.

Un projet de machine learning fait appel à la technique et à la gouvernance : pour une PME, il sera facile de faire l’inventaire de ses données et agir rapidement. Pour une multinationale, où chaque pays a son IT, ses bases de données et ses méthodes, le simple chantier de catalogage des données (quelles données disponibles, quel format, quel fréquence de mise à jour, comment les centraliser…?) peut représenter un travail monumental. Mais c’est le préalable à un projet de machine learning.

On ne peut pas avancer sans faire un tri des données, de leur format, de leur extraction, etc. C’est un chantier itératif, parce que par la force des choses on découvre de nouvelles sources de données. Il faut aussi travailler avec les experts du domaine et savoir quelles données leur semblent les plus importantes à analyser. Puis, identifier les sources de ces données et les centraliser. Si on a 1000 tables SQL, on n’en prendra peut-être que 10 ou 30, désignées par les experts métier, pour commencer le projet.

Et après le traitement de données ?

On commence alors à entraîner les premiers modèles, sans perdre de vue la réponse que l’on souhaite obtenir. Les premiers résultats arrivent assez rapidement, les projets de machine learning ne sont pas forcément très longs, en quelques semaines on peut déjà aboutir à un premier modèle opérationnel, avec un certain niveau de précision. A plus ou moins 3% de précision, c’est un excellent résultat. A plus ou moins 30%, le modèle n’est pas exploitable, et il faut essayer de comprendre pourquoi : a t on raté des sources de données clé ? Il faudra alors consulter à nouveau les experts métiers. Ou alors on n’a pas choisi le bon algorithme. Mais généralement, on arrive assez rapidement à 80-90% de précision, parce que les problèmes sont relativement typiques, les algorithmes et les méthodologies sont connues. 

Comment améliorer la précision du modèle et passer au-delà de 95% ?

Le coût marginal de la précision est fortement élevé, passer au-delà de 90 ou 95% demande plus d’efforts, et des compétences pointues. On entre alors dans la Data Science pure et dure.

Il faut comprendre où et pourquoi le modèle se trompe, c’est-à-dire analyser ce qui n’est pas prédit correctement. Prenons l’exemple de l’analyse de photos sur une chaîne industrielle de pièces mécaniques, avec 93% de précision sur la classification du type de pièces. On observe les erreurs sur les 7% restants, on essaie de comprendre pourquoi la photo de cette pièce a été classée par erreur dans la mauvaise catégorie. Il peut y avoir un défaut dans la photo (photo floue, objet tronqué, éclairage insuffisant…), ou on peut avoir deux types de pièces très semblables.

Quand cette analyse est faite, on peut faire ce qu’il faut pour améliorer la reconnaissance : dans cet exemple, soit améliorer la prise de photo, soit enrichir le jeu d’entraînement du modèle avec plus d’exemples de pièces, pour qu’il ait plus d’échantillons pour apprendre. Cependant, en fonction du modèle utilisé et des compétences disponibles dans l’entreprise, il n’est pas toujours facile d’aller chercher les derniers pourcentages de précision. Des services managés comme Amazon SageMaker peuvent aider à aller plus loin, en automatisant des tâches complexes et en intégrant des algorithmes à l’état de l’art et un ensemble de bonnes pratiques.

Comment vendre en interne un projet de ML ? Quel est le ROI ?

On revient au point initial : quelle est la question à laquelle on veut répondre? Si elle n’a pas de sens pour un CFO, CEO ou business owner, il n’y a aucune chance qu’il l’accepte. Le projet donc avoir un impact, d’où l’importance de formuler le problème en termes business, avec des métriques mesurables. Il faut trouver les bons indicateurs pour juger de la réussite du projet, fixer des objectifs initiaux qui soient raisonnables (la précision visée), établis en fonction des performances du process existant qui sera remplacé par le modèle. Ensuite, il faut identifier les acteurs de l’entreprise qui vont pouvoir aider.

Comment généraliser l’usage du machine learning suite à un POC ?

Quand on commence à cataloguer les sources de données, il est tentant de copier les jeux de données en local pour lancer son projet. Mais avec ce type d’approche, il y a peu de chances que le projet soit réutilisable, et la prochaine équipe devra à nouveau passer en revue les données et les outils d’ingestion. Les entreprises qui ont une vraie stratégie sur le sujet commencent par le sujet préalable du catalogage des données de l’entreprise, et leur centralisation dans un “datalake”, comme AWS Lake Formation. On y centralise les sources de données les plus pertinentes de l’entreprise. Définir une gouvernance, identifier qui mettra à jour les données… ce travail de fond doit permettre de faciliter l’accès des données aux Data Scientists. La construction du datalake est indispensable si on a pour objectif de mener un projet pilote pour avancer sur la méthodologie du ML avant de passer à l’échelle. 

Quelle est la bonne pratique sur le Datalake ?

On définit un processus d’ingestion de sources initiales, avec un nettoyage et une préparation des données automatisées. On dispose alors d’une copie propre des données sur laquelle pouvoir travailler. Ensuite, d’autres projets viendront connecter d’autres sources de données et ajouter de la valeur à l’existant. C’est un processus itératif, où il faut accepter d’expérimenter et de tester au départ. Le cloud est bien adapté à ce besoin, il est facile de démarrer et d’arrêter une infrastructure sans engager des coûts élevés. Il est important de pouvoir appuyer ses choix par ses expériences.

Comment capitaliser sur l’apprentissage et l’entraînement des modèles ?

Pour des problèmes du même type, par exemple la prédiction de métriques financières, on peut facilement réutiliser l’algorithme et la préparation des données à un autre jeu de données. On peut même parfois réutiliser les modèles si les problématiques sont très semblables, ou les re-entraîner (fine tuning) pour apprendre de nouvelles catégories. C’est le rôle de l’équipe data science de gérer ce catalogue de modèles. Autre option, utiliser un modèle (des algorithmes et des modèles entraînés) issu de la marketplace AWS . Des centaines de modèles créés par des partenaires AWS sont disponibles et certains d’entre eux peuvent répondre au problème qu’on essaie de résoudre. Il ne faut pas s’interdire d’utiliser un modèle déjà fait, qu’on déploiera rapidement avec Amazon SageMaker. 

Où en sommes-nous en termes de compétences sur le marché ?

Il y a un écart entre le nombre de personnes formées et le besoin des entreprises IT, notamment dans le domaine du cloud, la Data Science et le ML. On forme plus, donc il y a davantage de data scientists sur le marché. Les compétences recherchées évoluent aussi. Par exemple, les entreprises ont encore besoin de data scientists pointus, mais elles cherchent maintenant surtout à recruter des data engineers, ceux qui collaborent avec les data scientists pour aller chercher la donnée et la préparer. En effet, on passe 80% du temps à nettoyer la donnée, c’est un constante dans la data science. Et il faut de fortes compétences liées à SQL, Hadoop ou l’ETL. Ce que nous constatons est que les entreprises efficaces ont donc des binomes data engineers / data scientists. Aujourd’hui, la licorne, c’est le data engineer car le gros du travail reste la préparation de la donnée. Il y a de belles opportunités de carrière pour les profils data/ops ou devops.

Le mot de la fin ?

Les deux conseils que je donnerai à des clients voulant se lancer : identifier soigneusement ce sur quoi on veut travailler, et être lucide sur les compétences disponibles en interne, notamment sur l’utilisation des modèles. Il faut trouver le bon niveau d’abstraction : veut-on travailler à partir de zéro et construire un modèle, utiliser des modèles pré entraînés, ou utiliser des services de haut niveau ? Je conseille aussi d’utiliser le Cloud pour expérimenter rapidement ,à faible coût et à faible risque, et ensuite pouvoir déployer à l’échelle.