Keynote d ouverture Dev Day Paris 2018

Transcript

Parfait. Très bien. Merci beaucoup d'avoir répondu à l'invitation. Nous sommes très contents de vous accueillir aujourd'hui à Station F pour le premier vrai Dev Day AWS à Paris. Pour commencer de manière intéressante, nous avons choisi la thématique machine learning. Tout au long de la journée, vous allez assister à des sessions qui vous présenteront les différents services, les différents cas d'usage, et les différents clients qui utilisent le machine learning sur AWS. Je m'appelle Julien, je suis évangéliste technique pour l'Europe et le Moyen-Orient, et je m'occupe essentiellement de l'IA et du machine learning, ce qui est le sujet du jour. Sans plus attendre, nous allons commencer avec une première session qui fera un panorama des différents services et des différentes couches de services qui existent pour l'IA et le machine learning. Nous avons la chance d'avoir avec nous un de nos clients, BlueDME, qui vous parlera d'ici une trentaine de minutes de leur adoption du machine learning avec un service qui s'appelle SageMaker. Je ne veux pas trop en dévoiler, ils ont beaucoup de choses à vous raconter, et vous verrez tout ça tout à l'heure. Ce que vous savez peut-être ou pas, c'est que le machine learning chez Amazon, c'est une vieille histoire. Ce n'est pas quelque chose sur lequel nous avons commencé à travailler il y a deux ans. Dès le début d'Amazon, à la fin des années 90, la conviction de Bezos et des fondateurs d'Amazon était que le machine learning, la personnalisation de l'expérience client, la recommandation de produits, etc., étaient des éléments extrêmement importants. Très tôt sur le site Amazon, on a vu apparaître ce genre de fonctionnalités qui sont standards aujourd'hui, du moins je l'espère. Très vite, cette expérience et cette pratique du machine learning se sont propagées dans presque tous les secteurs d'Amazon. Évidemment, la logistique, vous avez certainement déjà vu les fameux robots Amazon qui se déplacent de manière autonome dans les centres logistiques, qui transportent les étagères et les amènent aux personnes qui préparent les commandes. Tout ça de manière autonome et intelligente. Nous expérimentons également avec des livraisons par drone, un service qui s'appelle Prime Air, qui n'est pas encore lancé mais qui est toujours en test. Des drones autonomes qui viennent vous déposer la commande sur le pas de la porte. Évidemment, Amazon Alexa, la famille de dispositifs Echo qui est maintenant disponible en France. Vous pouvez développer des Alexa Skills en français, allez-y. Plus récemment, Amazon a introduit une nouvelle façon de faire ses courses avec deux magasins à Seattle et j'ai vu ce matin qu'on annonçait l'ouverture d'un magasin à New York également. Il s'agit d'une épicerie où vous entrez, vous vous identifiez avec une application mobile, vous prenez des produits, vous les mettez dans votre sac, vous sortez et vous recevez votre facture quelques minutes plus tard sans passer par la caisse, simplement parce qu'il n'y a pas de caisse. Au plafond, un réseau de caméras regarde en temps réel quel produit vous prenez, lequel vous remettez, etc., et fait de la reconnaissance produit en temps réel pour vous envoyer votre facture. Si vous passez à Seattle, allez-y, c'est ouvert, c'est dans le centre, c'est ouvert à tout le monde. Évidemment, tout ça, c'est l'usage qu'en fait Amazon, mais mon rôle, et notre rôle chez AWS, est de vous aider à faire la même chose, de vous aider à adopter ces mêmes services et techniques pour construire vos propres histoires, rendre vos propres services et expériences clients intelligentes. Aujourd'hui, c'est sur AWS qu'il y a le plus de workloads de machine learning et d'IA. Cette liste ne concerne que nos clients publics. Nous avons des dizaines de milliers de clients aujourd'hui qui font du machine learning et de l'IA sur AWS. On trouve les très gros, les très connus, comme Netflix, Capital One, etc., et aussi plein de startups. J'ai dû ajouter un deuxième slide parce que la liste de références publiques s'est agrandie, et je pense qu'il faudra bientôt passer au troisième. Nous avons plus de références publiques que n'importe qui, et des dizaines de milliers de clients. Toutes les entreprises, toutes les organisations, des startups, de grandes entreprises, du secteur public, etc., font bon usage des services d'IA et de machine learning d'AWS. Aujourd'hui, nous avons une offre en trois couches. Une première couche de services applicatifs, donc des API que vous allez appeler et qui, pour la plupart, en temps réel, vous retourneront un résultat. Du paiement à l'usage, comme d'habitude. Aucune connaissance de machine learning requise. Des services plateformes, dont SageMaker, dont nous parlerons tout à l'heure, qui vous permettront, sans avoir à gérer d'infrastructures, d'entraîner des modèles avec vos propres données, de coder vos algos ou de choisir des modèles sur étagère, et ensuite de déployer des modèles toujours sans gérer d'infrastructures. Et puis au niveau le plus bas, vous pouvez toujours lancer des instances EC2, des instances GPU, CPU, installer TensorFlow ou PyTorch dessus. Là aussi, nous vous fournissons un ensemble d'outils pour vous simplifier la vie. Nous allons commencer par les services applicatifs. Je vais passer assez rapidement car vous avez vu dans l'agenda que les sessions suivantes entreront très en détail sur ces différents services. Nous ferons un petit panorama et ensuite mes collègues et amis vous donneront tous les détails. Le premier service dont je voulais parler, c'est Rekognition, qui est sorti à re:Invent en 2016, donc presque deux ans maintenant. C'est un service d'analyse d'images. Nous avons un jeu d'API qui va nous permettre de faire un ensemble de choses. La première, c'est la détection d'objets et de scènes. On passe une image et en temps réel, on reçoit une liste de labels avec un score de confiance qui indique ce qu'il y a dans cette image. C'est basé sur des modèles pré-entraînés. Tout ce que vous faites, c'est fournir votre image, la passer à cette API et récupérer le résultat. Aucune complexité de machine learning. On peut faire de l'analyse faciale. On peut détecter des visages dans des images, bien évidemment, la position de l'image, ce qu'on appelle la bounding box, les coordonnées, et un ensemble d'attributs, le sexe, l'âge, la détection d'émotions, si cette personne a une moustache, une barbe, des lunettes, etc. Et il y en a encore d'autres dans la liste. Ici, il n'y a qu'une image, mais on peut détecter jusqu'à 100 visages dans la même image. Voilà un exemple. C'est un workshop que j'ai fait en Grèce il y a quelques mois, on a fait un selfie à la fin, et vous voyez qu'on détecte bien tout le monde. On a les bounding boxes, les landmarks, les yeux, le nez, la bouche, etc., et pour chaque personne, on a les attributs. Et ça se fait en temps réel. Là, c'est un exemple dans la console AWS, mais bien sûr, le but est de le faire avec des API. On peut aussi faire de la comparaison de visages. On peut comparer deux images, ou on peut comparer une image à une collection d'images. On prend un visage dans la première image et on essaie de le trouver dans la deuxième image. Avec un score de confiance, ce qu'on appelle la similarité, qui indique à quel point la comparaison est précise. On peut faire plein de choses intelligentes avec ça. Un client, Aela Credit, une fintech africaine, utilise Rekognition dans son application mobile pour identifier ses clients. Dans les marchés émergents, il n'y a pas une agence bancaire à chaque coin de rue. Si vous avez besoin d'un micro-crédit, d'un prêt, etc., vous n'avez pas d'interlocuteur. Donc, s'il faut voyager 500 km pour aller à la banque, c'est assez compliqué. L'idée est que, une fois que les clients sont enregistrés, ils ont fourni leur passeport, etc., ils sont connus de la banque. Ensuite, en utilisant une reconnaissance faciale dans l'application mobile, ils peuvent dire « c'est bien moi » et demander un prêt de 100 $, 500 $, etc. L'authentification est suffisamment fiable pour autoriser des décisions de crédit en temps réel. Un autre exemple, un peu plus triste mais très utile, est Marinus Analytics, qui construit une suite logicielle utilisée par les forces de l'ordre pour trouver des personnes disparues, et en particulier des enfants disparus. Ils ont créé une collection de visages avec toutes les personnes manquantes, tous les enfants en particulier qui ont disparu. Ensuite, ils ont des crawlers qui se promènent sur Internet et les pires endroits d'Internet pour essayer d'identifier ces personnes. Lorsqu'ils ont mis cet outil en projet, l'année dernière, je crois que le deuxième jour, ils ont commencé à identifier des enfants et ont pu envoyer les informations aux forces de l'ordre pour qu'ils soient secourus. Voilà des cas d'usages différents où on voit que la reconnaissance faciale est suffisamment précise pour prendre des décisions aussi importantes que les deux exemples que je viens de donner. On peut aussi faire de la modération de contenu. L'idée est de vous donner le contenu suggestif ou explicite qui peut être présent dans une image, et de vous laisser décider. Nous vous donnons un score, par exemple, 83% de chance de voir une dame en maillot de bain. Si vous êtes un site qui vend des maillots de bain, c'est sûrement ce que vous voulez. Si vous êtes un site familial, peut-être que vous décidez que ce n'est pas tout à fait ce que vous vouliez afficher. Dans certains pays, dans certains contextes, dans certaines cultures, c'est une image qui n'est pas acceptable. L'idée est de vous dire ce qu'il y a dedans, de manière fiable, et de vous laisser décider si vous acceptez d'afficher ce contenu ou pas. On peut faire de la reconnaissance de célébrités. Voilà, mon ami Demis Roussos. C'est le test des moins de 25 ans. Il y a la moitié de la salle qui dit « c'est qui ? » Non, c'était mon slide pour la Grèce, c'était pour leur faire plaisir aussi. Là, ça leur a plu, ils savaient tous. Nous avons construit une collection de célébrités, des chanteurs, des sportifs, des acteurs, des hommes politiques, des hommes d'affaires, etc. Nous faisons de la détection de visages, nous vous disons de qui il s'agit, et dans la réponse que nous vous renvoyons, vous récupérez un document JSON qui vous dit, par exemple, Demis Roussos à 99%. Nous vous retournons également une URL qui peut être une URL Wikipédia ou une URL IMDB, ce qui vous permet d'avoir plus de contexte sur la personne détectée. Avec Rekognition, on peut aussi faire la détection de texte dans les images. Par exemple, on lit la plaque d'immatriculation et on voit la réponse concrète, le JSON retourné par l'API. Vous voyez que nous vous donnons précisément la bounding box, le texte, et si jamais il y avait plusieurs lignes de texte, vous auriez la position de chaque mot et la position des lignes. Ça vous permet aussi d'affiner. Ça marche avec du texte de ce style, ça marche si vous avez des logos. À partir du moment où les polices de caractère ne sont pas trop exotiques ou compliquées, ça marche plutôt bien. J'ai testé même avec du texte manuscrit écrit en majuscule, c'était pas trop mal. Donc, testez-le, ça marche plutôt bien. Nous avons étendu l'année dernière à re:Invent Rekognition avec la vidéo. Vous retrouverez tout ce que vous savez faire avec Rekognition, simplement avec un flux vidéo et donc plusieurs images, ce qui vous permettra de faire de la détection d'activités. Est-ce que cette personne joue de la guitare, se brosse les dents, etc. Nous pourrons évidemment faire du tracking, suivre une personne qui se déplace dans une vidéo. Ça marche avec des fichiers vidéo archivés, donc si vous avez des archives vidéo dans S3, vous pouvez les utiliser. Et si vous avez des flux, donc si ça vient d'une caméra, une caméra à votre porte, une webcam, etc., vous pouvez aussi le gérer. Nous avons un service qui s'appelle Kinesis Video Streams. Kinesis, c'est notre service de messaging ultra-scalable, et il a été adapté pour fonctionner très facilement avec Rekognition. Vous poussez votre flux vidéo dans Kinesis, il arrive dans Rekognition Video, et vous faites de l'identification ou de la reconnaissance des visages en temps réel sur le flux. C'est assez simple à mettre en œuvre. Ça a été utilisé par Sky News pour le mariage royal. Si vous avez regardé Sky News en live ce jour-là, vous auriez vu Rekognition Video en action pour identifier les célébrités qui entraient dans l'église. Je pense que tout le monde reconnaît Elton John ou David Beckham. Le nom de la famille royale du Lesotho, là vous avez gagné un t-shirt si vous pouvez me les citer. On peut reconnaître beaucoup de gens. Nous avons un autre service qui s'appelle Polly, un service de text-to-speech lancé à re:Invent. C'est tout simple. J'espère que j'ai du son, s'il vous plaît, en régie. Je m'appelle Léa. Je suis la nouvelle voix française de Polly. Voilà. Tout simplement, vous prenez une chaîne de caractères, vous choisissez une voix. Aujourd'hui, nous avons plus d'une cinquantaine de voix différentes. J'ai perdu le compte des langages, mais je crois qu'il y a au moins 25 maintenant. En temps réel, vous récupérez une chaîne de caractères. Si vous avez un Echo à la maison, ça doit vous dire quelque chose. Léa, Alexa, c'est presque la même chose. Je pense que c'est la même chose. Salut, je m'appelle Léa. Je suis la nouvelle voix française de Polly. Oui, on aurait pu l'appeler Alexa. Le but n'est pas juste de faire de la synthèse vocale. C'est évidemment que la synthèse vocale soit de bonne qualité et aussi convaincante et humaine que possible. On peut utiliser un langage de markup qui s'appelle SSML. Voilà un petit exemple, on va l'écouter. On peut modifier l'intonation, la vitesse, etc., du langage pour le rendre plus réel et encore plus convaincant. Un autre exemple de SSML que nous avons ajouté il y a quelques mois est un effet de respiration. En ajoutant simplement un tag SSML, qui est celui-là, Auto Breath, Polly va automatiquement ajouter des pauses de respiration dans le texte. Salut, je m'appelle Léa. Polly est un service qui transforme le texte en paroles réalistes, vous permettant de créer des applications qui parlent et de bâtir une toute nouvelle gamme de produits dotés de paroles. On a entendu des pauses que je n'ai pas du tout gérées à la main, et on entend vraiment la pause de respiration. Tout ça de manière complètement automatique. Ça vous permet de rajouter des effets. Vous pouvez également les contrôler. Il y a d'autres exemples où on peut simuler, par exemple, l'essoufflement. C'est assez efficace, c'est assez spectaculaire. Le but de SSML est vraiment de customiser la façon dont le texte est prononcé. Nous avons beaucoup de clients qui utilisent Polly, c'est un service hyper populaire, tout simplement parce qu'il est très simple à utiliser, vraiment peu cher, et construire un service de text-to-speech aussi efficace dans toutes les langues est très compliqué. Un exemple de client qui l'utilise est Duolingo, une application pour apprendre les langues. Si vous l'avez déjà testée ou si vous l'utilisez, vous savez que très vite, au bout de cinq minutes, vous parlez vous-même et surtout vous entendez des petits clips audio dans la langue que vous essayez d'apprendre. Duolingo a constaté que la qualité de l'apprentissage, la vitesse à laquelle les étudiants progressent, est très liée à la qualité de la voix qu'ils entendent. Ils ont fait des tests A-B entre Polly et six autres fournisseurs de voix. Le critère de succès était la progression des étudiants. Ils ont constaté que dans les six cas, c'était avec Polly que les étudiants progressaient le plus. Maintenant, ils utilisent Polly pour toutes les langues supportées. Si vous utilisez Duolingo aujourd'hui, c'est Polly que vous entendez probablement. Un autre service lancé en preview à re:Invent et disponible depuis quelques mois est Translate, un service de traduction en temps réel. Aujourd'hui, voilà les langues que nous supportons. On peut traduire de l'anglais vers ces 12 langues ou de ces 12 langues vers l'anglais. Nous allons bientôt ajouter danois, néerlandais, finnois, hébreu, polonais et suédois. Il manque évidemment encore des langues, mais vous voyez que nous complétons. Au lancement, nous avions juste ces six-là, et depuis décembre 2017, nous avons déjà ajouté six plus les six qui arrivent encore. Et ça continuera à se développer. C'est un service tout simple, vous passez une chaîne de caractères, il détecte automatiquement la langue source, et vous lui dites dans quelle langue vous voulez traduire, et il traduit. Un client qui utilise Translate est MêmeSource, qui fait des outils de traduction cloud. Cela va bien au-delà de la traduction elle-même. Ils ont des outils comme des éditeurs web, à l'intérieur desquels vous affichez vos pages, et puis automatiquement vous faites vos traductions. Il y a un côté workflow, un côté design, qui va bien au-delà de la traduction du texte pur. Ils ont connecté Translate à cet outil. Donc, lorsque vous chargez une page, par exemple ici une page en anglais, au fur et à mesure que vous sélectionnez vos blocs, Translate en temps réel fait les traductions et traduit la page. Voilà un exemple, nous en avons beaucoup d'autres. C'est un service qui répond aux besoins d'énormément d'entreprises. C'est un service qui marche bien. Encore un autre service s'appelle Transcribe, le petit frère de Polly. Polly, c'était du texte-to-speech, Transcribe, c'est du speech-to-text. On prend un clip audio et on le retransforme en une chaîne de caractères. Aujourd'hui, nous supportons l'anglais et l'espagnol. Nous aurons d'autres langages au fur et à mesure. Vous aurez évidemment le texte, la ponctuation, les timestamps, le timing exact de chaque mot. Si vous voulez faire du sous-titrage, par exemple, c'est très important. Nous supportons la qualité IFI, bien sûr, et la qualité téléphonique. C'est important, car il y a beaucoup de clients de ce service qui opèrent des call centers et qui veulent automatiquement transcrire les appels des clients pour ensuite faire de l'analyse, etc. Il faut pouvoir le faire avec une qualité téléphonique qui n'est pas toujours très bonne. Nous reconnaissons les différents speakers, pas les personnes évidemment, mais nous vous dirons speaker 1, speaker 2, speaker 3, etc. Et enfin, vous avez la possibilité de charger du vocabulaire custom. Si vous êtes dans le domaine médical et que c'est une conversation médicale, il y a un jargon médical compliqué, vous pouvez donner à Transcribe une liste de mots en disant voilà, vous risquez d'entendre ça dans la conversation, et ça lui permettra d'avoir une reconnaissance un peu plus fine. Un client qui utilise ce service est RingDNA, une plateforme de collaboration pour les équipes de vente. Elles peuvent collaborer en interne, organiser des réunions, faire des appels en interne, ou faire des appels avec des clients. La fonctionnalité intéressante ici est que tous les appels, toutes les conférences, toutes les discussions voix qui ont lieu sur cette plateforme sont automatiquement retranscrites avec Transcribe. Cela signifie que vous ne passez plus jamais une minute de votre vie à prendre des notes en réunion et surtout, vous n'oubliez rien. Si vous parlez à un client, vous vous concentrez sur le besoin du client, l'écoute du client, et pas sur la prise de note. À la fin de la réunion, vous avez le compte-rendu, vous pouvez l'envoyer à votre client et avancer plus vite et ne rien oublier. Des cas d'usages simples, mais sans doute très difficiles à faire soi-même. Le dernier service de haut niveau dont je vous ai parlé est Comprehend. Comprehend est un peu différent. C'est un service qui va faire du traitement du langage naturel. Il fonctionne de deux façons. La première, c'est que vous passez un document, donc ça peut être un document Word, du texte, ou ça peut être un tweet, quelque chose de très court, un post Facebook. Avec différents appels d'API, vous pouvez faire de l'extraction d'entités, donc de qui ça parle, de quoi ça parle, de quel lieu ça parle, les phrases clés, donc quelles sont les parties importantes du texte, la détection de langage, on détecte 100 langages de manière fine, et une analyse de sentiments, donc positif, négatif, neutre. Clearview Social utilise Comprehend. Clearview Social est un outil destiné aux entreprises qui permet aux salariés de ces entreprises de poster sur les réseaux sociaux. L'objectif est que ces messages soient les plus impactants et efficaces possible. En utilisant Comprehend, Clearview Social va extraire automatiquement des posts, les mots clés importants, les entités importantes, et c'est avec ça que les messages seront tagués. On fait les bons choix, et ça permet même de mesurer le ROI de ces posts et de comparer le coût équivalent qu'il aurait eu sur Google AdWords, par exemple. Si on avait dû acheter ces mots-clés, combien ça nous aurait coûté. Ça leur permet de mesurer le ROI des posts de leurs employés. C'est un cas intéressant. La deuxième façon d'utiliser Comprehend est ce qu'on appelle le Topic Modeling. Cette fois, on travaille sur une collection de documents. Imaginez que vous avez un million de documents, par exemple du Washington Post, et vous voulez les grouper en 8 topics, en 8 sujets. Mais vous ne connaissez pas les sujets. Vous ne pouvez pas lire un million de documents en disant que les 8 sujets dominants sont ceux-là. C'est là que Comprehend intervient. Comprehend va automatiquement analyser ce million de documents et construire 8 topics. Un topic est une liste de mots interconnectés. Par exemple, s'il y a beaucoup de documents financiers dans votre base, vous risquez d'avoir un topic avec des mots comme « revenue », « earnings », « CFO », « Wall Street », etc. Un ensemble de mots qui reviennent souvent et qui ont un poids important pour décider de quoi parle ce document. Si vous avez beaucoup de documents sur le machine learning, vous risquez d'avoir des mots comme « prediction », « model », « TensorFlow », « AWS » j'espère aussi. Comprehend construit les listes de mots qui correspondent aux topics et donne pour chaque document un score pour les différents topics. Cette information n'est pas volumineuse par rapport à la base documentaire. Vous pouvez prendre le résultat, le mettre dans un cache ou une base de données, et très rapidement faire des requêtes comme « sors-moi les 10 documents qui ont moins d'une semaine et qui ont le plus haut score sur Machine Learning et Stock Market par exemple. » Cela vous évite de faire des recherches en texte intégral sur un million de documents, ce qui n'est pas toujours la meilleure solution. Voilà pour les services de haut niveau. Vous voyez, une belle petite famille. Le point commun de ces services est qu'ils sont des API, la plupart fonctionnent en temps réel, à part le Topic Modeling et Transcribe. Du paiement à l'usage, à chaque fois que vous appelez une API, vous payez une fraction de cent. Et surtout, absolument pas besoin d'entraîner un modèle, absolument pas besoin de connaître quoi que ce soit au machine learning, n'importe quel développeur junior peut se servir de ça en cinq minutes. Il y a évidemment plein de cas où on a des données, on veut entraîner son propre modèle, on veut contrôler finement l'apprentissage, on veut utiliser son propre algo, etc. Il faut passer un cran plus bas sur ce qu'on appelle les services plateformes. Là, on ouvre cette porte, et on se rend compte que c'est beaucoup plus compliqué qu'appeler une API et récupérer un résultat. On a un ensemble de difficultés, et les gens qui font du machine learning dans la salle vivent ça tous les jours. Vous avez des difficultés de préparation de données, de choix d'algorithmes, d'infrastructures de training, d'infrastructures de déploiement. Il est 10 heures. Merci. C'est pas poli, mais bon. Il va falloir que je l'éteigne ce truc-là. Voilà, ça a cassé ma concentration. Nous avons un ensemble de difficultés inhérentes à l'infrastructure dont nous avons besoin pour entraîner et déployer des modèles de machine learning. C'est pénible, tout comme c'était pénible d'être englué dans l'infrastructure quand on voulait déployer des applications métiers ou web. C'est tout aussi pénible, voire encore plus pénible, lorsqu'on veut faire du machine learning. Parce que quand on veut faire du machine learning, on veut faire du machine learning. On ne veut pas s'amuser à déployer des clusters, à déployer des serveurs pour la prédiction, à les scaler, etc. On veut faire du machine learning et passer son temps sur la compréhension des données, l'algo, le tuning, etc. Pour résoudre ce problème, nos clients nous ont parlé de leurs difficultés, et nous avons construit un service qui s'appelle SageMaker, lancé à re:Invent l'année dernière. SageMaker vous permet de manière simple de construire, d'entraîner et de déployer des modèles de machine learning sans gérer du tout d'infrastructure. Quelle que soit l'échelle, que vous soyez à petite échelle ou à une immense échelle, l'infrastructure devient complètement transparente, elle est pilotée par deux ou trois API, et vous verrez avec BlueDME dans quelques minutes à quel point c'est devenu simple. Vous vous concentrez sur le machine learning lui-même. SageMaker est une collection de modules. Nous avons un composant qui s'appelle la notebook instance, dont parlera BlueDME, qui est une instance de développement que nous vous fournissons avec Jupyter préinstallé et toutes les librairies préinstallées pour que vous puissiez commencer à expérimenter tout de suite. Si ça vous intéresse, vous vous en servez, sinon vous utilisez directement le SDK. Nous avons aussi une collection d'algos built-in, donc nous avons maintenant 13 ou 14 algos de machine learning développés par Amazon et AWS pour résoudre les grands problèmes du machine learning, comme la régression linéaire, la classification, XGBoost, PCA, K-Means, Factorization Machines, Anomaly Detection, etc. Ces algos sont disponibles sur étagère, donc vous n'avez même pas à coder de machine learning. Vous dites, par exemple, que vous voulez faire un clustering avec K-Means, vous prenez l'algo K-Means, vous mettez vos données dans S3, vous appelez K-Means, il fait son boulot, et vous récupérez le modèle. Nous avons aussi des environnements préinstallés pour les grandes librairies de deep learning, comme MXNet, Chainer, TensorFlow, PyTorch, mais vous pouvez amener ce que vous voulez. C'est le cas de BlueDME, qui a construit son propre environnement et vous en parlera tout à l'heure. Une fois que vous avez choisi votre algo, vous pouvez ensuite entraîner votre modèle, et vous verrez que c'est un appel d'API. Vous pouvez faire de l'optimisation sur les hyperparamètres, donc automatiquement lancer un mécanisme qui vous recommandera le bon learning rate, le bon paramètre pour tel ou tel algo que vous avez choisi d'utiliser. En le faisant assez intelligemment, c'est vraiment utiliser du machine learning pour faire du machine learning. Nous exécutons un petit nombre de trainings avec des paramètres choisis intelligemment, et en appliquant de l'optimisation à ces résultats, nous vous recommandons les bons paramètres. Cela vous permet de converger plus vite vers le bon jeu d'hyperparamètres et la meilleure précision. Pour le déploiement, c'est ma partie préférée. Dans mes vies antérieures, c'était un cauchemar, c'était le plus dur. C'était prendre un modèle dans la sandbox data science et l'amener en prod. C'était vraiment le pire truc, et maintenant c'est vraiment le truc le plus simple. C'est vraiment un appel d'API, en fait, deploy, et vous déployez ça sur une flotte de serveurs qui est maintenant gérée avec de l'autoscaling. Vous n'avez même plus à vous préoccuper du scaling de votre infrastructure de prédiction, elle variera automatiquement. Voilà, j'en ai fini pour ce panorama. Je reprendrai la parole tout à l'heure pour parler de la couche la plus basse, des frameworks et de l'infrastructure. Je pense qu'on peut les applaudir parce qu'ils ont beaucoup bossé. Merci beaucoup. Bonjour. Et donc ils vont vous parler de la mise en œuvre du machine learning et de SageMaker chez BlueDME. Et nous y voilà. C'est parti, à vous messieurs. Bonjour à tous, merci d'être venus si nombreux. Merci à Julien et à AWS pour cette invitation. Donc nous, comme disait Julien, on va vous parler de comment on fait chez BlueDME pour mettre en production des modèles de data science. Un petit sommet rapide, je vais commencer par introduire qui est BlueDME, ce qu'on fait, et puis Tommy rentrera dans la partie plus technique et vous expliquera comment on faisait du machine learning avant SageMaker et les changements qu'a apporté SageMaker. Et enfin, on vous dira ce que ça apporte, ce que nous on prévoit de faire par la suite. Donc moi d'abord je me présente Mohamed, lead data scientist chez Blue DME. Donc voilà, moi je suis la partie sandbox qui crée les modèles et ainsi de suite. Enfin je représente cette partie. Et Tommy représente la partie data engineering, déploiement des modèles en production, etc. Un petit historique rapide sur Blue DME. En fait on est une startup créée en 2014. Dès 2016, on a fait nos classes dans l'automobile avec notre premier client. Et en novembre 2017, on a décidé de mettre un focus sur la performance commerciale et les assistants virtuels. Alors ça, c'est notre cœur de métier. La performance commerciale, qu'est-ce que c'est pour nous ? C'est dans le domaine de l'automobile en particulier et aussi dans l'assurance où on se développe actuellement, c'est mettre à disposition, c'est une approche humaine basée sur le Big Data et l'intelligence artificielle, pour nous c'est mettre à disposition du commercial des insights ou des infos pertinentes sur un comportement client pour que lui puisse avoir une action efficace et rapide, ce qu'on appelle nous des next best actions. Et pour appuyer sur le développement commercial, on s'appuie sur une équipe plutôt tech et orientée data. 12 techs sur 16 personnes, 7 data engineers et 5 data scientists. Une équipe tech pour des problématiques vraiment techs, on traite aujourd'hui environ 1 150 000 événements par jour. On est à ce niveau-là, mais ça augmente de façon exponentielle. 8 Teraoctets de données, 20 sources de données en temps réel, et en combinant le nombre de modèles et le nombre de cas d'usage qu'on sait traiter chez BlueDME, aujourd'hui on a une vingtaine de modèles en production. Et tout ça, comme vous voyez sur une stack AWS, les différentes bases utilisées. Alors qu'est-ce qu'on fait chez BlueDME ? On fait du data processing, mais dans nos cas d'usage client, en l'occurrence, c'est notre client à son site web sur lequel on a des trackers, on collecte tous les événements. Ces événements rentrent via l'API Gateway qui est le point d'entrée dans nos bases de données finalement, et c'est traité classiquement via une queue et puis un ETL, ici en l'occurrence un cluster Spark EMR, donc voilà pour la partie data processing. Et ensuite les données peuvent atterrir dans deux endroits, soit dans un cluster Redshift pour la liste de données et la création de modèles à l'usage des data scientists, et d'un autre côté, des données qui vont aller directement dans les bases opérationnelles et qui vont servir justement Tony, notre assistant virtuel, et qui pourra pousser les infos aux commerciaux, les infos aussi pouvant être disponibles via des interfaces web, et ainsi de suite. Donc j'ai parlé de création de modèles. Chez nous, notre création de valeur, elle repose sur le fait que les modèles aillent en production. Donc on a nos modèles qui sont créés et qui sont mis en production, et les données, les prédictions qui sortent de ces modèles vont aller aussi dans les bases opérationnelles à destination de Tony et des commerciaux. Un petit historique sur la data science chez BlueDME, on avait l'habitude de faire un petit peu des modèles sur mesure au début, donc à la demande des clients, et donc le déploiement forcément de ces modèles se faisait dur. Comme disait Julien, c'était l'enfer, on faisait comme ça et on n'avait pas le choix. Ce qui évolue aussi, c'est en termes de taille d'équipe, j'étais le seul data scientist chez BlueDME jusqu'à 2016, on a deux recrutements en 2017, deux de plus, au premier semestre 2018, on continue à recruter, donc on est pas loin, on est en double de taille quasiment chaque année, en termes de data science. Et donc la démultiplication du nombre de modèles, et la conclusion à ça, c'est qu'il fallait absolument trouver un moyen pour rationaliser notre façon de mettre en production des modèles. Donc tout ça, c'est des problématiques nouvelles, des problématiques qui sont assez spécifiques, et qui sont finalement... Alors, on connaît le DevOps qui gère des applications, ici, c'est le DataOps qui gère des applications qui sont orientées data et c'est très différent finalement. Le DataOps, c'est un terme nouveau qui est apparu en 2015 dans un blog post de Brian Palmer qui est le CEO de Tamer. Le DataOps, son métier, c'est faciliter le lien entre les différents métiers de la data, faciliter le fait que j'ai des modèles et que je veuille les mettre en production, donc les pousser au Data Engineer. Et plus concrètement, une des problématiques pour les plus avertis, c'est que vous avez envie de versionner les données sur lesquelles vous avez entraîné votre modèle, pour avoir un modèle donné et pouvoir reproduire ce que vous avez fait. Et il y a aussi le fait d'avoir différentes sources de données, où votre client ne maîtrise pas ces sources de données, donc vous êtes obligé de vous adapter, et là le DataOps rencontre aussi ce type de problématique. Donc nous, pour traiter toutes ces problématiques-là, on a créé notre cycle de vie du modèle, par rapport à nos cas d'usage, comment s'orienter, mise en prod, on a défini notre cycle de vie que je vous montre là. Vous avez la phase exploratoire, charger les données, comprendre les données, créer le modèle, l'améliorer, le fine-tuner, ainsi de suite. Donc ça c'est plutôt le travail du data scientiste. Et ensuite, il faut que le modèle soit en prod, vous allez l'entraîner et faire des prédictions. Et dans vos prédictions, selon le cas d'usage, vous avez parfois besoin de faire des prédictions par lot ou en batch, donc une fois par jour, ou des prédictions en temps réel. Pour les prédictions en batch, c'est le cas d'usage, par exemple, où le commercial arrive le matin, il a sa liste de clients qui est scorée, et puis il les appelle par ordre de score, par exemple. Pour le cas temps réel, ça va être justement pour Tony, qui va détecter un comportement sur le site web d'un client en particulier, et qu'il va se rendre compte que le client a fait un financement, par exemple, et ça veut dire qu'il devient chaud, et ça, le commercial a l'information directement. Pour le monitoring, alors ça, c'est la partie un peu moins rigolote, mais vraiment, on a un besoin pour pouvoir itérer sur nos modèles, pour pouvoir les améliorer, et donc, pour nous, ça doit rester dans le cycle de vie du modèle. Une fois qu'on a défini ce cycle de vie-là, on s'est dit comment on résout ça. On a eu des choix techniques à faire. Les choix techniques, c'était soit trouver un modèle sur l'étagère type ce que propose Amazon un peu haut niveau, ou alors développer quelque chose en interne. En 2017, nous, on a fait notre état de l'art des solutions de machine learning à ce service, mais en fait il n'y avait pas de solution qui correspondait à notre besoin pour des raisons variées comme le coût, la flexibilité ou la stack technique qu'on utilisait. Du coup, on s'est dit, on va développer notre propre solution en interne qu'on a appelé booster parce que ça servait à booster le déploiement des modèles, et cette solution avait pour but de coller à notre cycle de vie. Sans vouloir faire de concurrence Amazon, on s'est dit qu'on a un truc sympa, il n'y a rien sur le marché, et pourquoi pas commercialiser cette solution ? Mais heureusement Amazon et SageMaker sont arrivés. Je vais maintenant laisser Tommy rentrer plus dans les détails et vous expliquer la partie un peu plus technique. Voilà Tommy. Merci. Je t'en prie. Moi je vais vous raconter l'histoire de l'évolution de nos processus en Data Science, qui a commencé au début de l'année 2017 et qui a été transformée dès la sortie de SageMaker au milieu de l'année 2017. Pour illustrer le type de problème qu'on peut rencontrer au quotidien, un petit dialogue entre Roy Data Scientist et Moss qui va être Data Engineer. Donc Roy veut mettre en production, il a trouvé le bon modèle, il va donc rendre son code à Moss qui va essayer de le mettre en production. On voit déjà un premier problème, tu n'as pas utilisé la même version de Python, je n'arrive pas à exécuter ton code. Ah oui, c'est vrai, j'ai oublié de te le dire, mais je suis passé en version 3.6. D'ailleurs, de ton côté, est-ce que tu n'as pas oublié de prendre une machine assez grosse pour l'entraînement, parce que contrairement aux mises en production précédentes, cette fois-ci, on a besoin d'un peu plus d'espace. Ah oui, je vais devoir éteindre la machine, je vais devoir la redimensionner, la rallumer, je vais le faire, très bien, pas de soucis, mais cette fois-ci, on a encore un autre problème, les données en production sont un petit peu différentes de ce que tu peux avoir dans ta sandbox, donc on a encore des problèmes. Je t'envoie l'erreur, on va corriger ça. Et donc là, on voit que ça fait des allers-retours, et c'est comme ça qu'on peut perdre du temps. On arrive toujours à cette phrase, au final, « Pourtant, ça a marché sur mon poste de travail, ça a marché dans mon notebook. Et quand on a prononcé ce genre de phrase, c'est qu'on n'a pas suffisamment réfléchi au processus de déploiement. Donc par exemple, comment passer de l'environnement de test, de la sandbox, à l'environnement de prod. Cette réflexion doit être à deux niveaux, aussi bien sur la communication entre les différents services, les différentes équipes, qu'au niveau de l'infrastructure elle-même sur laquelle on va déployer notre code. Et cette réflexion doit être menée sur chacune des étapes du cycle de vie que Mohamed vient de vous présenter. Le but, ça va être de faciliter chacune des étapes individuellement et de faciliter la transition entre les étapes. Donc typiquement pour la première phase, la phase exploratoire qui va se passer dans le notebook, il faut donc une machine sur laquelle ce notebook est hébergé et aussi prendre en compte qu'on va devoir faire sortir le code pour mettre ça sur des machines de production. Alors, cette machine, nous, en interne, on l'appelle Data Lab. Ça va être l'endroit où, justement, on va charger les données, on va faire des expérimentations, c'est plus une partie qui s'adresse aux data scientists. Donc, quelles sont les caractéristiques, quelles sont les fonctionnalités qu'on souhaiterait sur cette machine ? Donc la première, simplement, le dimensionnement. Il doit être dynamique puisque le data scientist ne sait pas par avance quelle va être la taille des données qu'il aura à charger. Il voudra donc pouvoir lui-même éventuellement contrôler ce paramètre-là. Un besoin de sécurité, évidemment, puisque des données clients transitent sur ce serveur, sur cette machine. On ne veut pas laisser l'accès à n'importe qui. Un besoin de sauvegarde automatique. Ainsi que des notebooks qui représentent des journées de travail du data scientist et même les meilleurs peuvent avoir une machine qui tombe, ça et là. Donc avoir ce mécanisme en place est très important. Des connecteurs de données pour deux raisons, des besoins de sécurité et d'autre part parce qu'on voudrait uniformiser par exemple la manière dont les data scientists vont se connecter aux bases de données SQL s'ils utilisent tous la même librairie, on va gagner du temps lors de la mise en production. La gestion multi-utilisateur sur cette machine-là, donc si par exemple deux data scientists travaillent sur deux modèles différents pour le même client, on pourrait éventuellement leur donner la même machine, mais ça pose peut-être des problèmes de gestion des espaces de travail, gestion d'allocation des ressources, machines, donc CPU, RAM, et toute la question c'est comment faire pour ne pas se marcher sur les pieds, pour ne pas accaparer toutes les ressources d'une machine. Et enfin, un modèle n'est pas simplement un modèle du code, c'est aussi un ensemble de dépendances, un ensemble de librairies avec leurs versions associées. Et pour travailler de concert, en général, on utilise les environnements virtuels qui est une solution classique en data science. Alors, pour répondre à toutes ces problématiques, on a développé une solution qui suit cette architecture-là. Typiquement, nos données sont sur S3 ou Redshift, donc dans l'infrastructure Amazon. Pour les notebooks, on les a sauvegardés sur EFS, qui est un système de fichiers montés en réseau, qui permet, même lorsqu'on éteint la machine, de ne pas perdre notre code. Et au niveau de la machine de data lab elle-même, on a deux services. Le notebook Jupyter lui-même est un service de visualisation des informations hardware, NetData, qui permet de surveiller tout ce qui est CPU, RAM, etc. Tout ça est protégé derrière un proxy d'intensification et contrôlé via une interface qu'on a appelée nous, le DataLab Manager. D'où vient cette interface, qu'est-ce qu'elle permet de faire ? On avait un cas d'usage en tête, Mohamed qui arrive souvent en premier le matin au bureau, il voudrait lui-même commencer à travailler sur un modèle. Le mieux c'est qu'il soit indépendant, qu'il puisse allumer lui-même sa machine, ne pas devoir demander aux data ops, à un autre service d'attendre quelqu'un pour pouvoir gérer lui-même l'infrastructure. Evidemment, s'il y a un autre data scientist qui arrive, il pourra aussi lui-même faire de même. Et chacun pourra être indépendant de ce point de vue-là. Éventuellement, on arrive à la fin de la journée, ils rentrent chez eux, on va éteindre les machines, puisque c'est de toute façon ce que nous permet le cloud d'Amazon, d'offrir cette flexibilité-là. Et Mohamed veut continuer à travailler, il veut lancer un job d'entraînement un peu gourmand ressource, on va dire un entraînement sur des données de production. Il va vouloir lancer une plus grosse machine cette fois-ci, qui va tourner toute la nuit parce que ça peut être un peu long. Pour répondre à toutes ces problématiques-là, on s'est dit qu'on va faire une interface de contrôle et on ne va pas simplement demander aux data synthesis d'utiliser la console Amazon, on va faire un front-end. Donc que voici. Et d'ailleurs, on va prochainement proposer une AMI pour ceux qui seraient intéressés par ce genre d'interface. Donc n'hésitez pas à nous suivre sur les réseaux sociaux pour avoir plus d'informations sur les actualités de cette AMI. Une fois que le data scientist a déterminé le meilleur modèle, le but va être de mettre en production. Mettre en production, ça veut dire quoi dans un premier temps ? Entraîner le modèle, puis l'utiliser pour faire des prédictions par exemple journalière. Sachant que ces deux étapes vont s'exécuter pas forcément sur la même machine, pas forcément le même jour. On peut choisir d'entraîner le modèle une fois par semaine, de faire des prédictions tous les matins, par exemple, tous les jours. Et donc pour répondre à ces problématiques, on doit aussi imaginer un certain nombre de caractéristiques pour nos machines. Donc on retrouve des caractéristiques qu'on a déjà vues. Donc le dimensionnement, il faut en effet dimensionner la machine d'entraînement en fonction du dataset d'entraînement, dimensionner la machine de prédiction d'eux-mêmes. Et par contre, on a une problématique qui est la sérialisation du modèle. Alors, d'où vient cette problématique ? On va l'expliquer avec un schéma. Dans un notebook, le data scientist va faire apprendre son modèle sur de la donnée d'entraînement. Donc typiquement, s'il fait du pricing, ça va être de la donnée qui va être un catalogue de voitures avec leur prix associé. Il va faire apprendre son modèle, et puis il va instantanément l'utiliser pour générer des prédictions de tests qui lui permettront d'évaluer son modèle. En production, c'est un petit peu différent, puisque le but va être de... Donc on a toujours cette étape d'entraînement, et cette fois-ci on va sauvegarder le modèle sur disque, et c'est cette étape-là qu'on appelle la sérialisation. Pourquoi on sauvegarde sur disque ? Puisque le lendemain, éventuellement, on va vouloir utiliser ce modèle entraîné sur une autre machine, dans un autre contexte, on va charger ce modèle et l'utiliser pour générer des prédictions. Donc c'est là qu'on voit qu'il y a directement des problématiques de versionning, comment on fait pour charger le bon modèle, où est-ce qu'on va le stocker, etc. Tout ça, c'est des problématiques auxquelles on doit réfléchir quand on veut mettre en production. Une autre problématique, c'est la planification. Donc en effet, il faut lancer ces jobs, à une certaine date, qui est prédéterminée par la nature des prédictions qu'on cherche à servir. Il existe plusieurs solutions. Apache Airflow, qui permet de décrire des pipelines d'exécution et qui est donc adapté au paradigme de data science, ou alors de simplement utiliser les commandes crone, les tâches crone. Chez nous, on avait un service d'automatisation déjà pré-existant qui était Rundeck, donc on a décidé et de continuer à l'utiliser pour déclencher nos tâches de machine learning. Et enfin, la comptabilisation, qui permet de reproduire les environnements virtuels qui étaient utilisés par nos data scientists en phase exploratoire. Donc notre solution doit avoir tous ces éléments-là. Et pour y répondre, on a donc une architecture qui peut ressembler à ça, un scheduleur qui va déclencher les et il va déclencher soit une tâche d'entraînement, soit une tâche de prédiction, et au final, on va déposer nos prédictions dans la base de données opérationnelles, et les commerciaux pourront avoir, par exemple, le prix d'une voiture conseillée par notre algo. Cela dit, certains types de modèles de data science ne sont pas adaptés à des prédictions journalières, ce n'est pas suffisant. Typiquement, si on a un visiteur web on voudrait pouvoir déterminer instantanément lui attribuer un score et savoir s'il faut l'appeler en fonction des clics en fonction des événements qui va produire sur ce site web donc là on doit prédire en temps réel prédire en temps réel ça veut dire quoi ça veut dire une machine qui va être une application web qui doit aussi être dimensionnée sécurisée encore une fois qui doit reproduire l'environnement du data scientist le conteneur. Et cette fois-ci, on doit se préoccuper de l'architecture applicative, aussi bien au niveau du framework que de l'infrastructure qu'on doit gérer nous-mêmes. Et enfin, il faut avoir en tête que lorsqu'on déploie une application web, on va avoir un certain nombre de données qui vont arriver, qu'on ne maîtrisera pas, qui peuvent être des données partielles, mais le but va être de servir une prédiction. Donc la gestion de ces cas d'exception est très importante puisqu'on va devoir éviter les erreurs, éviter les interruptions de service, et il faut toujours avoir ça en tête quand on veut mettre en production un modèle qui était au départ prédiction par lot, on veut le mettre en prédiction temps réel, il faut avoir ça en tête aussi. Donc voilà, il faut avoir un certain nombre de problématiques, de fonctionnalités quand on veut mettre en production de la data science, la vie d'un modèle de data science ne commence pas et ne s'arrête pas dans un notebook Jupiter. On a mis en place une série de solutions et en 2018, le produit SageMaker a été sorti quelques mois auparavant, on a décidé d'adopter, de commencer à voir si on pouvait utiliser ce produit-là pour accélérer encore plus notre mise en production et changer nos usages. On va voir comment. Changer nos usages est évidemment sur chacune de ces étapes-là qu'on vient de voir, sachant que SageMaker avait une idée aussi du cycle de vie en data science. Donc par exemple, Julien vous parlait des notebook instances, c'est ce que nous on appelait des data labs, et donc on va voir un peu ce qu'il en est. Il a à noter que nous on a plutôt regardé la partie modèle sur mesure plutôt que modèle sur catalogue et on va voir comment l'utiliser. Alors pour les notebook instances, un certain nombre de fonctionnalités qu'on avait prévu d'avoir, qu'on a sur notre DataLab sont présentes et un certain nombre de fonctionnalités ne sont pas là. Donc la sauvegarde des notebooks automatiques, les connexions aux données, les connecteurs de données, la gestion multidisateur, tout ça n'est pas par défaut présent sur les notebooks instances. Donc voilà, globalement, ce qui nous a plu, ce qui nous a moins plu. Et je voudrais mettre l'accent sur deux points qui me paraissent importants. C'est l'extensibilité de ce système via les configurations du cycle de vie. Typiquement, ce sont des scripts qui vont s'exécuter au démarrage de la machine qui permettent éventuellement de rajouter des features, même si elles ne sont pas présentes par défaut, on peut les rajouter. Cela dit, on ne voulait pas perdre trop de temps à recoder des choses, des éléments qu'on avait déjà, donc on a décidé de continuer à utiliser notre solution de Data Lab. Et puis c'est aussi un avantage, c'est de pouvoir choisir sur SageMaker quand est-ce qu'on rentre, quand est-ce qu'on sort. On peut par exemple ne pas utiliser cette première étape du cycle de vie, on peut ne pas utiliser les Notebook Instance, et utiliser le framework, le SDK, pour les étapes suivantes, l'entraînement, la prédiction. Donc du coup, les étapes suivantes, toutes ces problématiques sont gérables via SageMaker. On peut dimensionner les machines, on peut déployer des conteneurs, tout ça est présent. Au niveau de la sérialisation, elle, elle est simplifiée puisque les modèles sérialisés vont être déposés de manière quasi automatique sur S3. La planification n'est pas intégrée mais il existe des services Amazon comme les Lambdas qui permettent de gérer ça par ailleurs. Et la connexion aux données, elle, ne peut s'effectuer que sur des données S3, déposées sur S3. Du coup, qu'est-ce que ça implique ? Ça a des avantages, des inconvénients. On va commencer par les inconvénients. Si vos données sont sur une base de données SQL, il va falloir les exporter de manière régulière. Il va falloir faire un script qui permet de faire ça. Cela dit, ça nous oblige à suivre une bonne pratique qui va être de versionner nos données sources et nos schémas. Ça permet de reproduire les entraînements, ça permet d'expliquer les modèles entraînés, donc ça a ses avantages et ses inconvénients. Et évidemment, comme d'habitude, cette infrastructure est managée par Amazon, donc on ne peut pas se connecter en SSH dessus. Le schéma d'architecture globale qui ressemble à ce qu'on a déjà pu voir sur notre solution sur mesure. Donc là je parlais du planificateur, du scheduler, on peut utiliser le service lambda, il va déclencher un job d'entraînement qui va prendre les données sources, s'entraîner, déposer un modèle serialisé sur S3. Le service de prédiction par lot que SageMaker appelle batch transform job est sortie cet été, il y a moins de deux mois et on n'a pas encore eu l'occasion de l'utiliser mais on voudrait bien tester. C'est pareil, il va prendre des données d'entrée et il va servir des prédictions qu'il va déposer sur S3 sachant qu'on peut stocker le modèle sous forme de conteneur soit sur ECR soit sur Docker Hub. Au niveau des prédictions en temps réel, qui étaient elles par contre une fonctionnalité qui était intégrée dès le départ dans SageMaker, ça permet de déployer des applications web, donc avec toutes ces caractéristiques qui sont gérées. L'infrastructure qui va être elle managée, mais on a quand même le choix du framework, donc si on est en Python par exemple, de faire du Django ou du Flask, c'est laissé à la charge du. Au niveau de l'utilisation de ce produit-là, avant par exemple, quand on voulait faire un entraînement, on devait construire l'image Docker, créer la machine, créer le cluster, déployer les services sur les clusters. Maintenant, en quatre lignes, on peut faire la même chose tout simplement. Il suffit de préciser le nombre de machines, la taille des machines, où sont les données d'entraînement, le job va s'exécuter tout seul. Pour le déploiement d'une API de prédiction, il fallait connaître un service pour faire ça. Nous, on utilisait Elastic Beanstalk, on devait de la même manière déployer notre application en ligne de commande, donc ce n'est pas forcément facile pour tous les data scientists de le faire, en l'absence de leurs collègues. Ici, une ligne de Python, qui est d'ailleurs le langage de prédiction de beaucoup de data scientists, donc ils peuvent eux-mêmes déployer leur API de prédiction de test et derrière, avec toujours une librairie en Python, faire des requêtes, tester ces cas d'exception dont je parlais tout à l'heure, tester les erreurs et ça permet d'éviter des problèmes qu'on peut avoir en production. Et enfin, le dernier élément important dans le SDK, qui nous a plu, c'est le monitoring intégré par. Quand l'application web est déployée, un certain nombre de métriques sont disponibles par défaut. Donc ça va être le nombre de requêtes sur l'application, donc le nombre de prédictions émises, le nombre d'erreurs, et le temps de réponse moyen des endpoints. C'est quand même un avantage intéressant, et puis je vais laisser de toute façon Mohamed conclure. Merci beaucoup. Merci. Vous avez eu à peu près un panel de ce qu'on faisait, ce qu'on a adopté grâce à SageMaker. Pour résumer, vous voyez, on avait tout plein de services à gérer nous-mêmes avant SageMaker, et à droite, vous avez ce qui nous reste finalement comme services à manager nous-mêmes. C'est lié aussi au fait qu'on ait choisi de garder notre propre data lab, parce qu'on a travaillé dessus, qu'on a des features intéressantes. SageMaker permet de se débarrasser de pas mal de choses. La métrique importante qui est à noter aussi, c'est que pour mettre en déploiement des modèles de data science, avant on était à un ordre de grandeur de quelques semaines, avant SageMaker, aujourd'hui, grâce à SageMaker, on est plutôt dans une grandeur de quelques jours. Donc le gain est assez conséquent. Notre retour d'expérience pour aborder SageMaker pour être dans les meilleures conditions, c'est d'abord, si vous anticipez et que vous avez déjà vos données qui sont sur S3, vous avez une facilité d'entrée d'emblée. Vous pouvez par exemple utiliser AWS Database M3, migration service pour se faire. On a vu aussi que le monitoring, que ce soit Booster ou SageMaker, aucune des solutions n'apporte quelque chose qui gère ce point-là. Donc vraiment, c'est un point où on considère qu'il faut s'y attacher vraiment dès le début. Et enfin, SageMaker permet de garder le focus sur la production de valeur en évitant de manager tous ces services-là, de débuguer à un moment donné, etc. Donc vraiment, vous allez pouvoir avoir un focus sur la création de valeur. Ceci étant dit, on a identifié un certain nombre de features sur SageMaker qu'on n'a pas encore utilisées aujourd'hui. Tommy vous parlait de batch transform qui correspond à la prédiction par lot, il n'y a plus qu'un en fait, il n'y a plus qu'à mettre en application. On a identifié l'A-B testing, alors je dis A-B testing entre guillemets parce que c'est plus du green, blue deployment, dans le sens où vous avez plutôt des métriques techniques pour choisir la machine cible plutôt que des métriques métiers. Et nous on attend vraiment le de pouvoir faire ça avec des métriques métiers et de mettre en place de l'A-B testing. Et du coup, Tommy vous a montré le monitoring CloudWatch, mais qui est finalement un monitoring applicatif, donc vous avez suivi le temps de latence, le nombre d'erreurs 404, etc. de votre application. Il y a le monitoring CloudWatch personnalisé qui est dispo dans en SageMaker et qu'on voudra utiliser pour suivre des KPI business, par exemple, ou alors des métriques plus techniques de nos modèles de data science. Merci à tous de nous avoir écoutés. Je vais repasser tout de suite la parole à Julien. Merci beaucoup. Merci beaucoup. Merci. Ils recrutent, ils ne l'ont pas dit, mais moi je peux le dire à leur place. Si vous voulez faire du machine learning et du AWS et du SageMaker, c'est pas un mauvais endroit. Alors, on a vraiment eu un concours. Quand on a commencé à préparer cet événement, on a regardé plein de clients différents. La raison pour laquelle j'ai vraiment choisi BlueDME, c'est parce que, évidemment, leur cœur de métier, c'est faire du machine learning pour créer de la valeur pour leurs clients. Et c'est sur ça qu'ils veulent se concentrer. Donc ce que moi j'appelle vulgairement la plomberie, gérer des clusters, gérer du DevOps, se lever le week-end, la nuit, pour scaler, pour réparer, passer ses journées, effectivement, à comprendre pourquoi le modèle ne se déploie pas en prod. C'est l'histoire de ma vie. J'annonce d'emblée que je vole le slide de conversation. Je me l'approprie, donc vous allez le voir à partir d'aujourd'hui. Ça a été l'histoire de ma vie pendant un moment. Je trouve que leur pragmatisme est vraiment... est vraiment louable. Et on se rend compte qu'il y a une meilleure solution qui nous libère d'un ensemble de tâches qui ne sont pas au cœur du business, qui nous permet d'accélérer et de mieux servir nos propres clients. Ils y vont, ils n'ont pas d'état d'âme, mais vous voyez, ils s'approprient le truc très, très vite. On a eu une bonne discussion hier sur ce que devrait être la roadmap. Bravo et merci beaucoup d'être venus aujourd'hui. C'est vraiment une super histoire. Je voulais vous donner un autre exemple de clients qui utilisent SageMaker. BlueDME vient de commencer, je leur souhaite d'atteindre l'échelle que DigitalGlobe peut avoir. DigitalGlobe, c'est une société qui opère une flotte de satellites d'imagerie, et qui passe leur temps à photographier la planète. Ils existent depuis un moment maintenant et ils ont accumulé plus de 100 pétabytes d'images. Vous n'êtes pas là les gars ? On ne peut pas encore ? Bon, ça va venir. Appelez-moi. Le but du jeu pour eux, c'est évidemment d'automatiser le maximum de traitements. Vous vous doutez bien que quand on a 100 pétabytes de données, on ne peut pas faire autre chose que du machine learning et de la prédiction pour extraire l'information d'images. Voilà un exemple de photos satellites, où on a envie de compter des avions sur un tarmac, on va entraîner des modèles de reconnaissance d'images, etc. Ça, c'est le métier de Digital Globe, c'est de collecter ces images, et puis de fournir aux entreprises, à tous leurs clients, des services à valeur ajoutée pour extraire de l'information. Donc, ils font ça à longueur de journée avec SageMaker. Mais ils ont un deuxième problème, qui est intéressant, qui est un usage interne. J'ai mentionné qu'ils avaient 100 pétabytes de données. Je vous laisserai aller voir combien ça coûte d'avoir 100 pétabytes de données dans S3. Ça coûte un peu d'argent. Et ils se sont dit qu'il y a peut-être moyen d'optimiser un peu ce truc-là, parce que toutes les photos de la planète ne se valent pas. Il y a sûrement, de manière normative, des cartes qui sont plus utilisées, plus accédées que d'autres. Ils se sont dit, est-ce qu'on a vraiment besoin de laisser tout ça en ligne, en temps réel, dans S3 ? Ils ont essayé de construire par eux-mêmes un modèle de machine learning qui leur prédisait finalement dans quel serveur de stockage une image devait aller ? Est-ce qu'il faut la laisser en ligne dans S3 ? Est-ce qu'on peut l'archiver avec Glacier qui est un service d'archivage offline qui vous permet de récupérer vos données en 3-4 heures ? Ils se sont un peu cassé les dents sur le sujet et ont travaillé avec nous. On a une équipe de consulting qui s'appelle Machine Learning Lab, qui est une équipe globale, qui travaille avec les clients pour les aider à décortiquer des problèmes de machine learning et qui les met sur la bonne voie ensuite, pour qu'ils puissent le faire eux-mêmes. Donc ils ont bossé avec le ML Lab et en utilisant SageMaker, ils ont construit un modèle de prédiction qui leur permet de choisir automatiquement le bon service de stockage pour leurs images, donc qu'est-ce qui va dans S3, qu'est-ce qui va dans Glacier, etc. Puis à l'intérieur de S3, il y a encore des sous-classes de stockage. Et en faisant ça, en fait, ils arrivent à réduire leur facture de stockage de 50%. Vous imaginez sur un volume de données comme ça, c'est sans doute le projet de machine learning le plus rentable de l'histoire. Et je trouve que c'est intéressant de voir ces deux usages, c'est-à-dire un usage, on va dire, produit, cœur de métier, comment est-ce qu'on utilise du machine learning à l'échelle pour bien servir nos clients, et puis comment on l'utilise en interne pour se simplifier la vie. Et chez BlueDME, on voit un peu les deux aussi. Comment est-ce qu'on fait du bon machine learning pour les clients, puis comment est-ce qu'on s'appuie sur des services pour aller plus vite et gagner du temps. Donc je vois beaucoup ces deux thèmes chez les clients, et peut-être il y a des sujets aussi chez vous, je serais ravi d'en discuter. La dernière couche, vous vous souvenez, j'ai commencé par vous dire qu'il y a trois grandes couches dans notre offre Machine Learning, les services de haut niveau, Recognition, Poly et compagnie, la couche Platform, où on trouve aujourd'hui essentiellement SageMaker, et puis tout en bas, vraiment la couche, appelons-la infrastructure, où vous allez pouvoir tout simplement démarrer vos instances sur AWS, les configurer exactement comme vous voulez, vous avez la main complète sur ces serveurs. Il y a deux grandes familles d'instances EC2 qui sont à mon avis très pertinentes pour le machine learning. Une première famille qui s'appelle C5. Je vais juste faire un très bref rappel pour ceux qui ne sont pas parfaitement à jour sur AWS. On a plein de familles différentes de machines virtuelles. Elles ont des noms un peu bizarres. La lettre c'est la famille, donc C pour compute, ce sont des instances qui sont conçues pour avoir la plus grosse puissance de calcul, donc on va avoir des processeurs Intel, non seulement de dernière génération mais même custom pour AWS, on va avoir les dernières architectures, on va avoir vraiment la perf de calcul. Il y a tout un tas d'autres familles, tout simplement parce que c'est la cinquième génération. On a récemment lancé une variante des C5 qui s'appelle C5D qui dispose de stockage NVMe local donc SSD de dernière génération qui vous permet d'avoir localement sur les instances une performance d'Io qu'on peut qualifier de phénoménale. Donc bref, cette famille C5, c'est celle que je recommande en premier lieu aujourd'hui pour faire du machine learning et même du deep learning. Elle a la dernière architecture Intel qui s'appelle Skylake. L'intérêt de cette architecture-là, c'est que dans le jeu d'instruction Skylake, il y a un jeu d'instruction qui s'appelle AVX512, qui est un jeu d'instruction arithmétique 512 bits. Donc concrètement, ça vous permet de manipuler vos données 512 bits par 512 bits. Et quand on fait du machine learning et du deep learning, on passe sa vie à faire des multiplications de matrices et des additions de matrices. Et ce sont des choses qui se parallélisent bien. Donc si vous arrivez à les machiner 512 par 512, si vous avez un parallélisme hardware comme on l'a ici, évidemment, vos jobs vont beaucoup plus vite. Donc c'est vraiment une instance qui a été faite pour ça, qui a été faite pour le calcul et qui marche très bien en machine learning. De manière générale, l'amélioration de perf par rapport à C4, qui est l'ancienne génération, est aux alentours de 25%. Mais sur du machine learning, c'est beaucoup plus spectaculaire. Vous pouvez donc les utiliser avec SageMaker, vous pouvez les utiliser, on n'a pas parlé de... On a une session SageMaker tout à l'heure, mais on peut facilement faire du training distribué. Donc si vous avez besoin de 10 instances C5, vous lancez 10 instances C5 à la demande. Donc si vous avez des datasets qui sont même relativement volumineux, vous pouvez bien les travailler avec une flotte d'instances C5 gérées par SageMaker. Et en particulier pour de la prédiction, je recommande d'utiliser en plus ces instances-là pour faire de la prédiction, pour faire de l'inférence. Parce que la plupart du temps, vous allez prédire échantillon par échantillon, et même si vous faites de la prédiction d'images, même si vous faites du deep learning, généralement, on prédit une, deux images, on prédit rarement 256 images d'un coup. Et donc, l'équation économique est plus intéressante avec des instances de type C5 qu'avec des instances de type GP1. Je vois encore beaucoup de gens qui dépensent leur argent pour faire de la prédiction sur des instances GPU. Je pense que ce n'est pas nécessaire dans beaucoup de cas et qu'ils auraient un meilleur ratio prix-performance avec des instances C5. Ce n'est que mon avis, il faut que vous fassiez vos propres tests. La deuxième famille d'instances qui est importante, c'est quand même les instances GPU, je ne vais pas en dire du mal. Lorsqu'on a des gros data sets, en particulier des gros data sets de deep learning, de l'image, de la vidéo, du speech, enfin de la voix, etc. Dès qu'on passe sur du média à grande échelle, en particulier pour le training, les instances GPU et cette famille P3 qui supporte le dernier GPU Nvidia, le V100, qui est une machine de guerre, n'ont pas d'équivalent. Vous n'irez pas plus vite qu'avec ça. Cette famille P3 existe en différentes tailles. Vous pouvez avoir de 1 à 8 GPU. Dans la même box, vous avez 8 GPU V100. Ça donne un pétaflop de performance. Quand j'étais jeune, au siècle dernier, un pétaflop, c'était dans les classements des top 100 super ordinateur etc. Maintenant vous pouvez avoir ça à la demande sur AWS pour un prix à mon avis compétitif. Une fois que vous avez choisi vos instances, bien sûr vous pourriez démarrer Ubuntu ou Amazon Linux ou ce que vous voulez là-dessus et puis tout installer à la main mais histoire de vous simplifier un peu l'existence, on a créé une AMI, une Amazon Machine Image qui est le fichier binaire qui sert à créer la machine virtuelle. On a créé un ensemble d'AMI, qu'on appelle les Deep Learning AMIs, qui sont préinstallés avec, je ne vais pas dire tous les outils dont vous avez besoin, mais certainement un très grand nombre d'outils dont vous avez besoin. Donc vous allez trouver toutes les librairies de Deep Learning Populaire, vous allez trouver des environnements Python à jour, vous avez Konda qui est installé pour gérer les différents environnements, vous avez beaucoup de choses. On vient de rajouter ONNX, qui est intéressant. ONNX, c'est une initiative d'interopérabilité pour les modèles de Deep Learning. Ça vous permet de prendre un modèle PyTorch entraîné, de le charger dans MXNet en l'état et de l'utiliser réciproquement. C'est de l'import-export de modèles automatiques entre les librairies de Deep Learning. C'est un gain de temps phénoménal, même si le modèle qui vous plaît bien n'a pas été entraîné avec votre librairie de prédilection. Il y a une famille d'AMI avec le code source, sans le code source, etc. Tout ça s'appelle Deep Learning EMI, vous le trouverez sur la Marketplace AWS. Ces AMI sont gratuites, vous ne payez que pour l'instance sous-jacente, donc je vous engage au moins à l'essayer. Tous les gens que j'ai rencontrés qui l'ont essayé m'ont dit que ça leur faisait gagner du temps. Voilà donc sans doute ça vous en fera gagner aussi. Un petit exemple de gain que vous pouvez avoir, ça c'est un exemple de training sur C5. Donc c'est de l'entraînement de modèles de reconnaissance d'image. Donc les plus spécialistes d'entre vous auront reconnu le nom des CNN en bas. Et donc ce qu'on mesure là c'est à quelle vitesse on entraîne un modèle de reconnaissance d'image sur une instance C5, avec différentes architectures de réseau. Et on l'essaye dans deux cas. On l'essaye avec le binaire, c'est un test qui date d'il y a quelques mois maintenant, c'est TensorFlow 1.6, mais quelque chose me dit que ça serait pareil aujourd'hui. On entraîne avec le binaire standard TensorFlow, donc vous faites pip install TensorFlow, et c'est ça que vous récupérez. Ou alors, ça c'est la barre bleue, vous avez le nombre d'images par seconde. Ou alors, vous utilisez le binaire TensorFlow qui est sur la Deep Learning EMI, qui a été optimisé pour le hardware de la C5. En particulier, Intel fournit une librairie qui s'appelle MKL, que vous connaissez peut-être, Math Kernel Library, c'est un ensemble de primitives maths codées, hyper optimisées pour la micro-architecture Intel et Skylake en particulier. Plus d'autres optimisations qui sont faites par nos équipes. On a des équipes de dev qui ne font que ça, qui ne font que de l'optime de perf des librairies de deep learning. Donc vous prenez cette image qui est dans la deep learning EMI et en gros, à vue de nez, vous allez 5 à 6 fois plus vite. Donc ça veut dire qu'au lieu d'entraîner 6 heures, vous entraînez en 1 heure. Donc ça veut dire qu'en une journée, vous pouvez entraîner 4, 5, 6 fois et itérer beaucoup plus vite. Et évidemment, ces librairies-là sont aussi utilisées par SageMaker. Il y a aussi une partie performance. Ce n'est pas juste qu'on vous préinstalle les outils pour vous simplifier la vie. C'est aussi qu'on vous préinstalle les outils dans des configurations les plus optimisées possibles pour que vous alliez le plus vite possible dans vos process. Tout ça c'est bien, on s'est dit qu'est-ce qu'on peut... Le deep learning, le machine learning, ça excite les gens, qu'est-ce qu'on peut faire pour les aider à apprendre encore plus vite ? Et donc ce qu'on a fait l'année dernière à Reinvent, c'est qu'on a lancé un gadget pour les développeurs, c'est ma meilleure définition, qui s'appelle Deep Lens. Donc Deep Lens, c'est une petite caméra qui... qui va capturer un flux vidéo et qui contient une carte Intel, avec un Intel Atome et un mini GPU mobile, qui sont suffisamment puissants pour exécuter localement des modèles de deep learning. Donc on est capable de faire la prédiction localement sur la caméra. Et la façon dont ça marche, c'est qu'en gros vous allez entraîner un modèle Dans SageMaker, il y a une intégration entre SageMaker et DeepLens, donc vous entraînez votre modèle dans SageMaker, vous le déployez facilement sur DeepLens, vous déployez aussi une fonction lambda, donc le petit bout de code qui va prendre par frame, faire la prédiction et envoyer le flux vidéo modifié. Vous déployez le petit bout de code qui fait la prédiction et le modèle qui sert à faire la prédiction. Tout ça c'est assez facile, et vous pouvez en peu de temps, en quelques minutes, commencer à jouer avec ça. Il y a plein de projets, enfin plein, il y a une collection de projets déjà préinstallés, pré-disponibles, et effectivement, vous ouvrez votre DeepLens, vous l'allumez, vous la configurez, vous déployez un modèle, vous voulez faire de la reconnaissance de visage, ou de la reconnaissance chat et chien, J'ai fait ça avec mon chat, je me suis fait griffer. Pendant 10 minutes, ça disait que c'était un chien, donc il était vexé. Ça m'a valu des problèmes. Je vous conseille plutôt la détection du visage, c'est moins risqué pour vos bras. Mais blague à part, vous avez un ensemble de modèles préinstallés que vous pouvez déployer, vous pouvez commencer à jouer. En gros, ça donne ça. Ça, c'est une photo de ma télé. Donc il y a une deep lens face à nous qui fait de la détection d'objets. Alors la police est un peu petite mais on voit qu'on détecte bien la chaise, ça dit bien sofa. Là ça dit TV monitor, parce que dans les catégories reconnues par ce modèle il n'y a pas laptop mais c'est suffisamment prêt. Et mon fils et moi sommes reconnus comme Person, ce qui est rassurant en tout cas en ce qui me concerne. Et donc tout ça en temps réel. Donc voilà, une fois de plus, la façon dont ça marche, c'est que la caméra capture le flux vidéo. La lambda en boucle infinie prend une frame, utilise un modèle ici de détection d'objets, retourne la bounding box et la catégorie de chaque objet détecté et puis je crois qu'elle prend OpenCV et puis qu'elle trace un petit rectangle autour de la zone concernée et elle remet l'image dans le flux vidéo. Et donc vous pouvez visualiser sur votre télé ou ailleurs, vous pouvez visualiser le flux modifié. Évidemment la caméra est aussi connectée en wifi, donc si vous avez envie d'envoyer dans votre lambda, envoyer des messages IoT avec la liste des objets détectés, vous pouvez aussi le faire. Mais la caméra est suffisamment puissante pour fonctionner en autonomie. Vous pouvez la commander sur Amazon.com. Ce n'est pas encore livrable en Europe. Donc si vous allez aux US ou si vous avez un ami aux US, débrouillez-vous avec les US. Ça va arriver en Europe. Je n'ai pas encore de date à vous communiquer, mais on travaille activement sur le sujet que vous puissiez vous faire livrer en France et partout en Europe. Donc peut-être un cadeau de Noël, qui sait ? Un cadeau de Noël, c'est pas mal. On verra. Pour résumer, voilà ce dont on a parlé aujourd'hui. Notre objectif, c'est vraiment, quelle que soit la maturité de votre organisation en termes de machine learning, quel que soit votre propre niveau de consommation, et d'aisance avec le machine learning, de vous proposer des services qui vont vous aider à résoudre des cas d'usage bien précis dans vos applications. Donc les services applicatifs, pour tout ce qui est images, vidéos, voix, texte, etc. Si vous avez besoin de travailler avec vos propres données, comme on l'a vu avec BlueDME, ce que vous voulez faire, c'est vous concentrer sur le machine learning et pas sur la plomberie. Donc SageMaker est votre ami. Le service est à moins d'un an, il a beaucoup de succès. Et je vous recommande de l'essayer si vous en avez marre de gérer des serveurs ou si vous avez des problèmes de scaling ou des problèmes de multi-environnement, etc. Deep Lens, alors il faut bien le mettre quelque part, pourquoi pas dans les services plateformes. Donc DeepLens, qui est un outil vraiment d'éducation, de formation, si vous voulez un gadget concret pour faire du Deep Learning et du Machine Learning, voilà, DeepLens, ce n'est pas une mauvaise idée. Et puis bien sûr, au niveau le plus bas, je dirais le socle d'infrastructures scalables et sécurisées et hautement disponibles d'AWS. Donc tout ce que vous savez sur Amazon EC2, Amazon S3, etc. est toujours là. C'est disponible pour construire vos applis de machine learning. Ma recommandation, c'est de travailler le plus souvent possible avec des instances C5, quand c'est vraiment nécessaire, avec des instances P3, GPU. Et puis, je vous recommande aussi de jeter un oeil à la Deep Learning AMI si vous ne l'aviez pas regardée. Elle va vous faire gagner un temps précieux et vous pourrez vous concentrer absolument sur ce qui compte, c'est-à-dire vos datas, votre algo et vos paramètres. Voilà, j'en ai terminé pour cette première session. Si vous voulez plus d'informations sur tout ce dont j'ai parlé aujourd'hui, on a une URL facile à retenir qui s'appelle ml.aws, bien choisi. On a également un blog machine learning, technique, sur lequel vous allez trouver du code, des exemples, des architectures, des références, des témoignages clients, etc. J'ai également un blog sur Medium où je poste pas mal de choses. Il faut que je m'y remette, là, c'est la rentrée. Et puis, au fil du temps, j'ai accumulé aussi pas mal de vidéos machine learning, deep learning, IA sur YouTube. Donc, si vous avez raté, je ne sais pas, le Summit l'année dernière ou si vous voulez une session spécifique sur tel ou tel sujet, allez jeter un oeil sur YouTube, c'est possible. C'est possible que, soit dans mes propres vidéos, soit dans mes playlists, vous trouviez la vidéo que vous cherchiez. Et si vous voulez rester en contact et rester au courant de notre actualité, la meilleure façon de le faire, c'est de me suivre sur Twitter. Et bien sûr, si vous avez des questions par la suite, n'hésitez pas à me les envoyer sur LinkedIn ou Twitter. Je ferai de mon mieux pour répondre dans un délai raisonnable. Je voulais remercier une nouvelle fois BlueDME, Mohamed et Tommy. Je sais que vous avez beaucoup travaillé sur cette présentation. Merci beaucoup d'être venu. Et puis, écoutez, je vous souhaite une bonne journée. On a encore plein de contenus à partager. Je reviendrai tout en fin de journée pour une session SageMaker avec des démos et on verra, on verra de quoi on va parler. Il faut que je me décide. Merci beaucoup et bonne journée.