Amazon Machine Learning en demos

Transcript

Nous revoilà pour le deuxième webinaire de l'après-midi. Nous revoilà. Ils sont coupés. Ah là, j'ai été coupé. Ah non, mais là, attends, voilà. Très bien, nous revoilà pour le deuxième webinar de l'après-midi. Et nous allons maintenant parler d'un service qui s'appelle Amazon Machine Learning. C'est un service managé pour faire du machine learning, pour résoudre des problèmes de régression, des problèmes de classification semblables à ceux que nous avons vus tout à l'heure. Donc on va parler un petit peu du service évidemment, on va parler de ses fonctionnalités, on va parler de son positionnement, de son intérêt. Ensuite, je vous donnerai quelques exemples de clients qui s'en servent. On parlera évidemment un peu d'architecture, de comment on peut intégrer Amazon Machine Learning dans des architectures sur AWS, comment Predixis vient compléter Amazon Machine Learning également. Et puis bien sûr, on va faire une démo du service, on va prendre un dataset, on va l'entraîner, on va évaluer le modèle, on va déployer le modèle, et puis on va invoquer ce modèle à partir d'une application en Java. Et puis, on répondra à nouveau à vos questions. N'hésitez pas à les envoyer dès que possible pour que Hugo puisse les trier. Amazon Machine Learning, c'est un service qui a maintenant, qui doit avoir à peu près trois ans, et qui a été construit dans un but unique, on pourrait dire, qui est de simplifier le machine learning, de le rendre accessible à des développeurs qui ne sont pas des experts dans le domaine. Parce qu'on l'a vu tout à l'heure, dans le premier webinar, qu'on se retrouve très vite à parler d'algo, à parler de paramètres, à parler d'optimisation, etc. Vous avez vu mon exemple dans la feuille Excel qui manifestement vous a beaucoup plu, donc tant mieux. Très vite, finalement, on rentre dans des détails extrêmement fins dans lesquels on peut se perdre assez vite si on n'est pas un spécialiste. Parce que je vous ai vraiment montré des exemples simples, mais d'une part, les choses sont évidemment beaucoup plus compliquées que ça, d'autre part, il y a une quantité d'algos assez importante, et puis chacun de ces algos peut être paramétré et utilisé de plein de façons différentes, donc là aussi, la combinatoire devient compliquée. Et lorsqu'on a un problème assez simple à résoudre, on n'a pas envie, pas le temps, pas les compétences de passer des jours et des jours, pour ne pas dire des mois, à optimiser ce truc à la cinquième décimale. Donc vraiment, le but d'Amazon Machine Learning, c'est de rendre les choses simples. Si vous savez faire 10 lignes ou 20 lignes de Python, vous savez utiliser Amazon Machine Learning. On va le voir tout à l'heure, de Python ou de Java, si vous savez écrire 20 lignes de code, vous savez entraîner un modèle, vous savez le déployer et vous savez vous en servir. Donc c'est un service qui est simple, qui s'adresse à quelques classes de problèmes bien définies, donc qui ne conviendra pas à tous les types de problèmes. Moi, je l'appelle Amazon ML, je l'appelle l'autoroute vers le machine learning, c'est le terme que j'utilise, parce que c'est vraiment ça, c'est le moyen le plus simple d'aller du point A au point B. C'est de prendre l'autoroute. Donc s'il y a une autoroute et que votre véhicule est capable de rouler sur l'autoroute, prenez donc l'autoroute. Amazon ML, c'est ça. Si votre problème rentre bien dans les cases, il n'y a pas plus simple et on peut même, vous allez le voir, faire des modèles et pas écrire une seule ligne de code. Donc la contrepartie, comme je disais, c'est si votre problème est un peu particulier ou ne rentre pas dans les cases, vous ne pourrez pas utiliser Amazon Machine Learning. Mais ça vaut toujours la peine de jeter un œil à Amazon ML, c'est-à-dire, tiens, avant qu'on se lance dans des choses plus compliquées, est-ce que finalement on ne peut pas résoudre le truc avec Amazon ML, avec une précision très correcte, c'est fait en une journée, on n'en parle plus et on se concentre sur notre problème business et pas sur de la plomberie. Ce service est simple, mais il ne faut pas croire que c'est un service qui est bricolé ou anecdotique. C'est un service qui a été développé par Amazon, Amazon.com, qui est utilisé de manière intensive chez Amazon pour faire de la construction de modèles à l'échelle, etc. Et de l'utilisation, donc c'est quelque chose qui tourne, c'est bien huilé, ça marche bien, ça fait ce que ça doit faire. Le but du jeu, ça va être de prendre des données qui sont déjà dans AWS, on va voir quelles sont les sources de données possibles, et puis de créer un modèle, de définir quelques paramètres très simples et de créer un modèle. Et vous allez voir, vraiment, on va se poser finalement, on va nous demander de répondre à très peu de questions. Et puis surtout, surtout, surtout, une fois que le modèle est entraîné, en quelques secondes, on va pouvoir le déployer derrière une API HTTP et on va pouvoir utiliser cette API dans nos propres applications. Et on l'a dit tout à l'heure, ce fossé entre le monde de l'expérimentation, de la data science et le monde de la production, c'est un fossé qui est vaste et compliqué. Et là, on va régler ce problème. On va régler ce problème en quelques années. Donc c'est vraiment intéressant. Ce service, on peut s'en servir de deux manières. On peut s'en servir dans la console, c'est la démo que je vais faire aujourd'hui. Vous allez voir, lorsqu'on expérimente, c'est plutôt sympa de travailler avec une console plutôt que des API. Donc on va uploader notre dataset, on va observer des propriétés du dataset, etc. Et puis on va lancer l'entraînement du modèle. Bien sûr, je vais le faire dans la console, mais comme toujours chez AWS, tout est une API. Donc toutes ces actions peuvent être automatisées via l'un ou l'autre des SDK AWS. Et c'est là aussi l'un des avantages de ce service, c'est qu'on peut très facilement automatiser l'entraînement, le déploiement des modèles. Donc si c'est la croix et la bannière pour vous de déployer un modèle avec votre techno habituelle, là avec Amazon ML, vous pouvez entraîner et déployer 100 modèles par jour automatiquement. Spécialiser vos modèles pour vos différents cas d'usage, etc. Donc, on l'a dit, c'est un service qui provient de l'expérience interne d'Amazon. Donc, il est simple, certes, mais je dirais qu'il intègre les bonnes pratiques et les quelques bons réglages dont on a le plus souvent besoin. Donc, on ne trouvera pas tous les leviers, tous les petits boutons qu'on a envie de. Les données que vous allez utiliser pour entraîner votre modèle, elles peuvent être soit dans S3, soit dans Redshift, notre Data Warehouse, soit dans RDS. Donc si elles sont dans S3, très simple, vous allez pointer Amazon Machine Learning sur votre bucket S3 et les fichiers concernés. Si elles sont dans Redshift ou dans RDS, vous avez la possibilité d'écrire une requête SQL qui va aller extraire les données de la base. C'est un truc que j'aime bien parce que ça permet d'avoir des données plus ou moins... Donc les données peuvent être hébergées soit dans S3, soit dans Redshift, soit dans MySQL. T'es en Ethernet ton Wifi ? Je suis en Ethernet, oui. Donc c'est pas ça, hein. Je vais remettre le Wifi, hein. Ah, la bonne vieille époque, Adobe Connect. Putain. Et redémarre le tour épine. D'accord ? Ouais, j'ai pas d'autre solution. Turn it off and turn it on again. Je peux dire juste aux gens que c'est normal. ... Oui, bonjour tout le monde. Petit problème technique sur le bac de Géa. On redémarre le son. Enfin, on redémarre votre webinaire sur son ordinateur et on reprend juste après. C'est un cancer sur le plan de forme. Alors, est-ce que mon audio est revenu ? Oui, ça a l'air d'être bon. Ok. Voilà, désolé pour ça. Donc, je disais, pour ceux qui n'auraient pas entendu, les données peuvent être soit dans S3, soit dans Redshift, soit dans RDS. Donc, si elles sont dans S3, vous allez aller les piocher dans le bucket concerné. Si elles sont dans Redshift ou dans RDS, vous allez écrire une requête SQL qui va aller extraire les données de la base. Donc c'est sympa parce que ça permet de faire quelques transformations, un peu de filtrage, etc. Et puis les résultats de prédiction vont être écrits dans S3. Donc tout ça est entièrement managé. À aucun moment il n'est nécessaire de démarrer un serveur, de gérer l'infrastructure. C'est vraiment un service managé de haut niveau comme S3 finalement, où vous accédez au service et c'est tout. Vous n'utilisez rien de précis. Vous ne provisionnez rien, vous ne managez rien. Vous appliquez vos données, vous créez votre modèle et c'est tout. C'est vraiment pour des gens qui n'ont pas envie de gérer en plus de l'infrastructure. Parfait. Vraiment, c'est la bonne solution. En termes de coût, voilà le coût du service. Vous payez pour deux choses, vous payez pour le temps d'entraînement sachant que les durées d'entraînement ne sont jamais très très longues, on ne parle pas d'entraînement de 3 heures, je veux dire généralement c'est, dans mon expérience même avec des datasets un peu gros, on va être quelques dizaines de minutes, on est bien rare que ça dépasse ce genre de choses. Donc on va payer pour l'entraînement et puis on va payer pour les prédictions. Donc les prédictions qu'on pourra faire en batch ou en mode batch ou en mode temps réel, on va voir ça tout à l'heure. Mais bon, au final, finalement c'est un service qui ne coûte que si on s'en sert, ce qui est une bonne chose. Voilà, donc si vous entraînez, ça coûte un tout petit peu, si vous utilisez des prédictions, ça coûte un peu, si vous n'en servez pas, ça ne vous coûte rien. Il y a vraiment pas un tout petit frais fixe pour le endpoint temps réel qui aura été déployé, mais c'est vraiment négligeable. Un exemple de client qui se sert d'Amazon Machine Learning, on parlait de prévention de fraude tout à l'heure. Donc là, c'est une société qui s'appelle Fraude.net, dont les clients sont des e-commerçants essentiellement, donc qui aident les e-commerçants à décider si telle transaction faite par un des clients de ce site est frauduleuse ou pas. Et donc pour avoir travaillé dans l'e-commerce dans une vie antérieure, lorsqu'on veut faire ce genre de choses, on va essayer de prendre en compte plein de paramètres. Alors il y a des choses évidentes, effectivement, on va comparer l'adresse, l'adresse de livraison et l'adresse de la carte, on va regarder l'adresse IP, on va regarder est-ce que c'est quelqu'un qui a déjà commandé ou pas, on va regarder le montant de cette commande par rapport au commentaire, bref, il y a tout un tas de paramètres comme ça et ce qui est compliqué c'est qu'on a du mal à faire un modèle qui va intégrer tous ces paramètres. Donc on va plutôt faire un modèle par paramètre, on va avoir tendance à aller jusque là, faire un modèle par paramètre, par couple de paramètres, et puis on va faire un scoring global en parallèle sur tous ces modèles-là et puis on va calculer un score agrégé. Souvent, c'est ce qu'on fait. Et donc là, la capacité à entraîner plein de modèles en parallèle, à les déployer, etc., est importante. Et là, on voit, c'est ce que fait Fraud.net, ils ont plusieurs dizaines de modèles. Et s'ils veulent tester un nouveau modèle sur un nouveau paramètre, ils l'entraînent, ils l'ajoutent dans leur plateforme. Et j'ai envie de dire, et voilà, c'est pas... On dédramatise le fait de créer un modèle, déployer un modèle, c'est quelque chose d'assez simple. Et là, comme on le disait tout au début du premier webinaire, on ne s'appuie pas sur des intuitions, des règles métiers, des « oui, mais si l'IP, elle est comme ça, et que l'adresse de livraison, elle est comme ça, parce qu'une fois, on s'est fait avoir, oui, peut-être qu'une fois, on s'est fait avoir, bon, mais c'est un algorithme et un modèle qui doivent décider de ça, pas une intuition. » Le gut feeling, l'intuition, le « ah oui, mais je me souviens d'un truc ». Bon, non, laissez le modèle apprendre, et ici, laissez les modèles apprendre. C'est eux qui vont vous guider. Un autre exemple qui est assez rigolo, c'est une startup américaine qui s'appelle Upserve. Donc, ils font une suite logicielle pour les restaurateurs, pour les restaurants. Et une des fonctionnalités de... Attends un peu... Ça doit être le plus tarder de me faire je sais pas quoi, je parle trop vite, après tu vas me dire que je suis en retard, ouais, c'est pas différent, faire un bon vieux speed test, mais on m'entend pas ou non, non, ça c'est quoi ça qu'on fait. Donc deuxième cas d'utilisation d'Amazon Machine Learning, une société qui s'appelle Upserve, qui a une offre SaaS pour les restaurateurs. Il y a plein de modules dans leur offre, et il y en a un qui prédit aux restaurateurs combien de clients vont venir ce soir. Je trouve ça rigolo, c'est un usage amusant du machine learning, et c'est évidemment une donnée importante pour les restaurants parce qu'en fonction de la finance, ils doivent faire leurs achats, prévoir le nombre de serveurs, etc. Et donc voilà, ici aussi on a plein de paramètres, plein de modèles, et ce qu'apprécie observe, c'est finalement la capacité à construire ces modèles, les déployer, les utiliser, industrialiser ce processus de machine learning en étant pas un expert du sujet en n'ayant pas à gérer d'infrastructures. Pour des startups, c'est quand même important de se concentrer sur le produit. Ici, le cœur de l'activité c'est offrir des solutions au restaurant, c'est pas d'avoir une équipe de machine learning de pointe même si cette fonctionnalité leur est utile. Donc voilà, ils se concentrent sur le cœur de l'activité et puis le reste est délégué, on va dire, à Amazon Machine Learning. Alors comment est-ce qu'on construit... Vous allez voir, ça se passe en trois étapes, c'est simple. La première étape, ça va être d'entraîner le modèle. On va uploader des données, on va créer ce qu'on appelle une data source. On va analyser un peu cette data source, on va regarder quelle tête elle a. On va éventuellement faire quelques transformations si on en a envie, séparer des champs, regrouper des champs, ce genre de choses, appliquer quelques recettes. On va faire l'entraînement. Ensuite, une fois que l'entraînement est fait, on va évaluer la qualité du modèle. On va voir est-ce que c'est un bon modèle, il y a des métriques objectives qui nous permettent de savoir ça. Éventuellement, on va pouvoir régler un ou deux paramètres dans ce modèle. On va voir ça dans quelques minutes. Et puis, on va déployer le modèle et on va pouvoir faire soit des prédictions en mode batch, on va uploader un ensemble d'échantillons et puis on va demander une classification ou une prédiction. Ou alors on va déployer le modèle derrière une API et on va invoquer cette API pour faire des prédictions en temps réel. Voilà, c'est tout. Et donc on va passer à une démo. Donc je vais vous montrer, on va faire une régression linéaire. Maintenant que vous êtes au point sur la régression linéaire, on va jeter un œil au dataset quand même, c'est plus important. Voilà, ok. Donc c'est un dataset public de données bancaires. Qui ressemble à ça. Donc on a, je crois de mémoire, on a 20... enfin on a 20 colonnes, donc on a, on voit un rôle, ici on voit les descriptions, l'âge, le métier, le statut marital, le niveau d'éducation, etc. Tout un autre tas de paramètres. Donc ici on voit que cette première personne a 44 ans, c'est un col bleu, il est marié, etc. Donc on a 20 attributs. Et puis on a, un 21e attribut, en tout cas une 21e colonne, qui nous dit si cette personne-là a répondu de manière favorable à une campagne marketing. Donc là, on est vraiment dans la CRM et on essaie de prévoir si cette personne-là va répondre ou pas à cette offre. Ici, on voit par exemple que celui-là, eh bien, lui, oui, historiquement, il a répondu positivement à cette offre. Alors, on pourrait me dire, mais ce n'est pas un problème de régression, c'est un problème de classification, parce qu'on voit qu'il y a deux classes, c'est 0 ou 1. Mais en pratique, on veut vraiment faire une régression parce qu'on veut prédire une probabilité. Donc ici, il faut vraiment le comprendre, comme 0% et ici 100%. Sachant qu'évidemment, quand on va prédire, on va avoir une valeur entre 0 et 100. Donc ce qu'on veut, c'est sur la base de ce dataset qui comporte à peu près un peu plus de 40 000 lignes, on veut pouvoir construire un modèle et puis prédire de nouveaux échantillons et voir s'ils sont susceptibles de réagir ou pas à cette offre. Alors en avant, je l'ai déjà fait parce que vous voyez c'est des étapes qui prennent 3-4 minutes à chaque fois et c'est pas très intéressant de regarder, c'est aussi intéressant que de regarder les pas de cuir. Donc je vais faire les étapes, d'accord, et puis je vais vous montrer les étapes et puis on ne lancera pas l'entraînement, évidemment on passera à l'étape d'après. Tout commence par la création d'une data source. Ici on me demande où sont mes données. Ici elles sont dans S3. Elles sont dans ce bucket. Et mon fichier s'appelle banking.csv. On va donner un nom à la data source, on va l'appeler webinar. Original, on va vérifier qu'on arrive à accéder à ce fichier, ok, tout va bien donc Amazon ML a les bonnes permissions, voilà donc je peux accéder à mon csv, très bien. Donc là je vais pouvoir prévisualiser un certain nombre de choses, alors est-ce que la première ligne de mon csv contient les noms de colonnes, ben oui ça va m'être utile, voilà donc là je vois ici mes 20 colonnes, 10 là et 10 sur la page suivante. Et vous voyez qu'automatiquement, Amazon ML va comprendre le type de données. Donc évidemment, l'âge, c'est une valeur numérique. Vous voyez qu'on a le choix entre binaire, catégorie, numérique ou texte. Le job, c'est une catégorie. Le statut marital, c'est une catégorie. L'éducation, c'est une catégorie. Le reste, il y a beaucoup de catégories. Le mois, le jour de la semaine, ce sont des catégories. Puis on voit quelques exemples de valeurs, donc rapidement comme ça, on peut se dire « ok, ça a l'air bon ». Là, je vois qu'ici, j'ai des données purement financières, des taux d'emprunt, etc. Et là, par contre, on est bien sur des valeurs numériques. Donc voilà, de manière très simple comme ça, on peut s'assurer qu'Amazon ML a bien compris le type des données, on peut le changer si nécessaire. Bon, et puis j'ai ma 21e colonne, ici, qui est ici comprise comme un binaire, mais on va lui dire de faire autrement. Ok, donc mes données sont comprises, parfait. Alors, est-ce que je veux utiliser ce dataset pour créer ou évaluer un modèle ? Eh bien, oui. Et donc je vais lui dire, eh bien, ce que je voudrais... finalement c'est que tu apprennes à me prédire cette valeur. Donc ici, il va me faire un classifieur binaire, on va lui changer ça, on va lui dire que c'est une valeur numérique, continue, continue. Hop, je suis allé un peu vite. Voilà, donc on lui demande, et là il me dit, voilà, il me dit, j'ai sélectionné un attribut numérique comme étant la cible de la prédiction, donc, voilà, essayez de me faire une régression linéaire. Ok ? Donc automatiquement, il sait que, voilà, pour prédire une valeur, il va faire une régression linéaire. Donc vous n'avez pas à vous casser la tête sur quel modèle, quel algo, vous dites, voilà, tu veux, il faut que tu me prédises ça. Voilà de quel type c'est. Vous voyez tout à l'heure, c'était déclaré comme un attribut binaire, donc 0,1. Donc, il comprenait qu'il fallait faire une classification. On lui dit non, non, non, moi, je veux une probabilité. Donc, c'est un modèle de régression. OK, on continue. Mes données n'ont pas d'identifiants, non. Voilà. Donc là, on a la revue, la data source, la target, donc prédiction. Prédire une valeur numérique, donc on fait une régression, on crée la data source. Donc là il va ingérer mes données, ça prend quelques minutes, on va revenir au dashboard, je l'ai déjà fait, ok, et donc je vois ici, c'est la data source que j'avais ingérée hier, ici, et bien il va donc ingérer mes données, ok ? Puis ensuite, je vais lui dire, maintenant je vais créer un modèle. Donc je vais choisir une data source, donc je vais lui dire, tu vas partir de ça. Voilà les données qu'il va falloir apprendre. Alors ici, hier j'avais construit un modèle de classification, c'est pas grave, on va faire une classification. Il me propose un ensemble de paramètres par défaut, on va regarder les paramètres. Il me demande si je vais appliquer quelques transformations sur les données. Ici, on pourrait faire un peu de feature engineering, de consolidation de champs, de séparation de champs, etc. Il est capable de proposer par défaut un certain nombre de recettes. Je ne rentre pas dans tous les détails. On va lui faire confiance, on va dire ok, fais comme ça. On va lui dire oui, tiens, de mélanger le dataset, c'est toujours une bonne idée. On peut choisir le niveau de régularisation à appliquer. Sans rentrer trop dans les détails, la régularisation c'est une technique qui va permettre de générer un modèle qui généralise bien, donc un modèle qui ne va pas être trop spécifique à l'application au jeu de données qu'on est en train de lui fournir, mais qui va généraliser à des nouveaux échantillons. Donc on va dire très bien L2 reste là-dessus. Est-ce que j'ai envie d'évaluer le modèle ? Oui, donc il va, en fait, pour évaluer le modèle, il va garder une partie du dataset, il va couper le dataset en deux. Alors ici, vous voyez 70-30. Donc il va prendre 70% du dataset pour entraîner le modèle, et puis il va garder 30% hors entraînement et pour valider le modèle. C'est-à-dire qu'une fois que le modèle aura été entraîné, il va utiliser ces 30% d'échantillons pour les passer à travers le modèle et me donner une mesure de précision. Le fait important, c'est évidemment, ces échantillons, il ne les aura pas vus pendant le training, donc ce sera une mesure de la généralisation. On peut choisir comment on découpe, est-ce qu'on découpe séquentiellement ou random, on va aller dire tiens découpe en random, voilà, review, voilà, et là, très bien, paf, je clique là-dessus et il va créer le modèle. Et donc une fois qu'il a fait ça, au bout de quelques minutes, on va voir combien de temps ça avait pris hier, donc le modèle, vous voyez, il a pris 3 minutes, alors un petit peu plus parce qu'il y a le découpage, il y a 4 minutes pour le découpage, la création de la data source pour le training et de la data source pour la validation. Et puis l'entraînement lui-même prend 3 minutes. Bon, c'est des temps très courts parce que c'est vraiment un petit dataset. Sur des datasets plus volumineux, je ne sais pas vous, qu'est-ce que vous pouvez voir. Nous, nos solutions, ce qu'on propose, c'est un giga de données en 15-20 minutes. Voilà. Ce que j'ai dit que tu as l'air, c'est l'air. Moi, c'est ce que je vois, c'est quelques dizaines de minutes grand maximum. Ça compare aux journées de travail. Oui, voilà, c'est ça. Là, tout est fait complètement automatiquement. Donc c'est toujours pareil. Quand on est les bras croisés devant la console et qu'on attend que ça avance, ça paraît toujours trop long. Mais si on le compare à comment on ferait d'habitude, on se rend compte que les 3 minutes par rapport aux 3 heures ou aux 2 jours, ce n'est pas cher de payer. Donc le modèle a été entraîné. Donc ici, j'avais donc construit un modèle de classification puisque j'avais déclaré mon attribut comme une catégorie. On voit que ça a pris trois minutes, ce n'est pas très très long. Et une évaluation du modèle a été faite. Avec les 30% de données qu'on a mis de côté, on a mesuré la précision de ce modèle. Donc on voit des métriques, ici on voit une métrique qui est importante, qui s'appelle AUC, donc Area Undercurve, qui est une valeur entre 0 et 1. 0, c'est le modèle est catastrophique, il n'y a rien, en fait il n'y a pas de modèle, les données n'ont aucun sens. 1, c'est parfait, on arrive à construire un modèle qui couvre complètement les échantillons et qui prédit l'évaluation parfaitement bien. Donc 0,93 effectivement c'est extrêmement good. On considère qu'au-dessus de 0,9 on est bien. On est sur un modèle qui a un sens et qui mérite d'être exploité. Alors on peut avoir un peu plus d'informations sur les perfs. Et donc là on voit en détail, on voit que 91% des prédictions sont. Donc la précision, l'accuracy du modèle c'est 91%, donc on a le nombre de vrais positifs, le nombre de vrais négatifs, et puis on a 9% d'erreurs, on a quelques faux positifs et quelques faux négatifs. On a des métriques un peu plus avancées ici sur lesquelles je ne vais pas trop donner de détails pour ne pas vous faire mal à la tête trop dès le premier jour, mais sachez qu'elles sont là. Ce qui est intéressant c'est qu'on va pouvoir ajuster le modèle. Donc vous voyez, on va pouvoir faire bouger ce seuil. Donc c'est par défaut le seuil à 0,5. Donc on va considérer que si on prédit en dessous de 0,5 c'est 0, si on prédit au-dessus de 0,5 c'est 1. D'accord ? Mais on pourrait dire finalement, moi, ce que tu disais tout à l'heure, je ne veux pas de faux positifs. C'est-à-dire que je veux minimiser les faux positifs parce qu'un faux positif, ça me coûte de l'argent. Je vais appeler quelqu'un pour lui proposer une offre qui n'en veut pas du tout. C'est une mauvaise expérience client. Donc, je veux minimiser mes faux positifs. Je vais pouvoir décaler, et vous voyez ici les faux positifs. Je vais pouvoir décaler mon seuil pour minimiser les faux positifs. Alors évidemment, comme rien n'est gratuit en ce bas monde, si je diminue le nombre de faux positifs, je vais augmenter le nombre de faux négatifs. Donc ça veut dire que potentiellement, je vais passer à côté de gens qui auraient été intéressés, mais que je n'appelle pas. Alors prenons un cas moins rigolo. Imaginez que ce soit, on essaie de savoir si une tumeur est cancéreuse ou pas cancéreuse. Le dilemme du médecin, c'est de se dire est-ce que je préfère dire à mon malade qu'il a quelque chose alors qu'il a rien ou est-ce que je préfère lui dire qu'il a rien alors qu'il a quelque chose. J'aimerais pas être à leur place et je sais pas quelle est la bonne réponse à cette question là. Donc voilà, bref, vous voyez qu'on peut faire varier comme ça et inversement si on dit non non non on veut pas de faux négatifs on veut passer à côté de personne et ben on va minimiser le nombre de faux négatifs alors là par contre effectivement on fait varier le nombre de faux positifs. Donc là on va appeler des gens qui n'étaient pas intéressés. Donc voilà, le seuil, on va le faire varier. Donc si on le met par exemple là 0,23, eh bien on va considérer qu'en dessous de 0,23 la prédiction vaut 0, au-dessus de 0,23 elle vaut 1. Donc on comprend intuitivement qu'on va générer plus de faux positifs forcément. Donc voilà, l'évaluation a été faite, donc on peut sauver ce réglage-là. Et puis, une fois qu'on est satisfait de ce modèle, alors revenons sur les modèles, une fois qu'on est satisfait du modèle, évidemment, on va pouvoir s'en servir. Donc on peut s'en servir de deux façons, comme j'ai dit tout à l'heure, on peut s'en servir soit en faisant des prédictions en mode batch, soit en faisant des prédictions en temps réel. Donc très bien, là on va me dire qu'il faut faire une data source. Donc on va me demander une data source qui va contenir des échantillons de données sans le fameux attribut, puisque c'est bien le but, on veut le prédire. Donc ma colonne, il va manquer une colonne et c'est ça qu'on va prédire. Donc on upload cette data source là et puis Amazon ML va passer échantillon par échantillon, prédire une valeur et écrire les résultats dans le restaurant. Donc on peut faire du batch, et ce qui est plus rigolo, c'est évidemment de faire du temps réel. Et donc ici, alors je l'ai fait, je ne vais pas l'effacer, mais ici il y a un bouton qui s'appelle Create Endpoint, sur lequel vous appuyez, et les collègues ici peuvent témoigner qu'en deux minutes maximum, on a le endpoint. Et donc effectivement, j'ai une URL qui va me permettre d'invoquer mon modèle. Donc voilà Amazon Machine Learning, vous voyez, et on va faire évidemment la prédiction dans une minute, mais voilà comment fonctionne Amazon Machine Learning. Vous voyez, quand je dis que c'est l'autoroute, c'est l'autoroute. Donc si vous avez des problèmes qui sont des problèmes de régression ou des problèmes de classification, que vous arrivez à formuler un dataset propre dans S3 ou à l'extraire de Redshift ou de RDS, en deux ou trois appels d'API, deux ou trois clics, vous entraînez un modèle et vous le publiez. Alors bien sûr, comme je disais tout à l'heure, tous les problèmes ne rentrent pas là-dedans. Mais pour ceux qui rentrent là-dedans, c'est vraiment la solution la plus simple. Et elle ne nécessite aucun développement. Je n'ai écrit aucune ligne de code. Je suis... Je me suis contenté d'uploader mes données, de choisir quel type de modèle je voulais construire et le construire. Donc, j'ai mon endpoint. Maintenant, comment est-ce que je m'en sers ? Alors, on va basculer. On va quitter Firefox à l'instant. Et donc ici, j'ai écrit un petit bout de code. Donc là, qui est en Java, mais bien sûr, vous pourriez le faire en Python ou n'importe quoi, enfin n'importe quel langage supporté par SDK. Et donc ici, qu'est-ce qu'on fait ? Eh bien, on va récupérer, donc j'invoque ce programme avec l'identifiant du modèle que je veux utiliser, c'est un argument ligne de commande. Je récupère un client sur Amazon Machine Learning qui est dans la région irlandaise. Je vais lui demander de décrire tous les modèles existants, pourquoi pas, un exemple d'API Amazon Machine Learning. On va itérer sur ces modèles. Et puis si je trouve celui qui m'intéresse, celui que j'ai passé en ligne de commande, en identifiant les modèles que j'ai passé en ligne de commande, je vais afficher un ensemble de propriétés sur ce modèle. D'accord ? Donc ça fait un peu plus simple. Je vais afficher les propriétés du endpoint. OK ? Et puis ensuite, je vais faire ma prédiction. Donc je vais construire une requête de prédiction. Je vais l'associer au endpoint du modèle. Ensuite, je vais construire l'échantillon de données, ce que je veux prédire. Donc là, je construis un record qui va avoir les 20 attributs, les 20 premières colonnes de mon dataset, et puis je vais envoyer ma requête. Alors là évidemment, j'ai mis des valeurs en dur, on ne ferait pas ça, on est d'accord ? Parce que quelqu'un, pour la petite histoire, parce que j'aime bien les anecdotes, j'ai montré ça il y a quelques temps à quelqu'un qui était un spécialiste, il y a soi-disant, et qui me dit « Ah bon ? Donc chaque fois il faudrait écrire le programme je vous cache pas que c'est voilà cette personne a perdu en crédibilité bon petit pic mais voilà on les aime tous donc ici évidemment on met des valeurs en dur parce que c'est un exemple mais ça c'est des choses qui viendraient peut-être de RDS ou de Redshift ou d'un formulaire sur un site web, d'accord, on est bien d'accord que l'objectif ce serait d'avoir des données dynamiques. Non mais je préfère expliquer parce que parfois les gens sautent à des conclusions un petit peu hasardeuses. Bref, et donc ensuite on va prédire, donc là on va pousser cet échantillon sur l'API, et eh bien on va afficher le résultat de la prédiction. Voilà, tout simplement. Donc vous voyez là il y a 93 lignes de Java, je pense qu'en Python on le ferait en 20 lignes, mais j'aime bien Java quand même. Mais en tout cas il n'y a aucune complexité. C'est vraiment la différence sur ce qui est... Là on est sur un seul environnement, c'est-à-dire que les données étaient sur S3, donc le lake est sur S3, l'environnement du data scientist est aussi sur AWS, et le développeur qui doit intégrer ça a tout à disposition aussi dans l'environnement. Ce qui fait que dans un mode où on commence par définir le problème métier qu'on veut résoudre et qu'on veut définir une première solution très rapidement, le fait d'être dans un unique environnement permet en quelques minutes d'avoir un premier service qui tourne. C'est-à-dire que là, ces données que je vais prédire, je pourrais aller les chercher dans une copie de la base de prod. C'est-à-dire que si mes données clients étaient dans RDS, je demanderais à mon admin ou à mon DevOps, ou je le ferais moi-même si j'avais le droit, je créerais un snapshot de la base de prod, et puis j'irais piocher des données dans cette base, et puis je me dirais, tiens, sur des vraies données de prod, exactement ce que tu disais, pas sur un environnement, pas une sandbox, etc., sur des vraies données qui pourraient être directement tirées de la prod, comment est-ce que se comporte mon modèle ? Ce qui permet effectivement de tester en vrai, en grandeur nature, et pas de jouer avec un petit dataset de test pour me rendre compte qu'après, lorsque je saute de l'environnement data science à l'environnement prod, ça ne marche plus pareil, parce que les conditions ont changé. Donc ça c'est vraiment... Ce fossé entre l'environnement d'exploration et l'environnement de production, c'est sans doute une cause d'échec énorme dans les projets de machine learning. C'est beaucoup de désillusion au niveau du business. Chez moi ça marche, super, on fait une présentation, on fait un super slide avec des beaux résultats, puis après on le met en prod et ça ne marche pas parce que ce n'est pas les mêmes règles du jeu. Donc ici effectivement, tu as raison de le préciser, Sylvain, on est dans le même environnement et on pourrait travailler avec les vraies données. Allez, on va quand même exécuter ce truc-là, parce qu'on va voir le résultat. Donc ici, je l'exécute depuis mon poste. Je ne m'attends pas à des performances phénoménales. Donc, voilà, j'affiche mon modèle. J'ai bien son identifiant. Alors ici, c'était un modèle de classification binaire par exemple, parce que j'avais déclaré mon attribut comme une catégorie. Je vois que la data source qui a servi à faire le training, c'est bien ça. Le modèle est prêt, c'est une bonne nouvelle. L'endpoint est celui-là, il est prêt. Et par défaut, il accepte 200 requêtes par seconde. Bon, c'est la valeur par défaut, si on a besoin de la monter, on la monte, c'est pas un problème. 200 par seconde, c'est déjà une bonne prédiction. Alors je vois le temps de ma requête, 296 millisecondes, mais une fois de plus, c'est très long, mais je le fais depuis mon Mac, je traverse un réseau plus ou moins hostile jusqu'à la région, je vois Hugo qui dit, un réseau plus ou moins hostile jusqu'à la région irlandaise, donc ça prend du temps. On a un SLA sur ce service qui est que la prédiction doit prendre moins de 100 millisecondes à l'intérieur de la région. Donc si j'avais déployé ça sur une instance EC2 en Irlande, et que j'avais fait le même appel, j'aurais quelque chose d'inférieur à 100 millisecondes. Et donc je vois mon résultat, le score brut qui a été prédit, c'est 0,05, et en fonction du réglage du modèle, on considère qu'ici c'est un 0, donc ce sample-là, cette personne-là n'est pas un bon candidat pour mon offre en marketing. Donc vous voyez à quel point c'est simple ici de passer de l'environnement « j'expérimente, je bricole, je teste mes modèles » à « je le déploie en prod ». Je dirais que le problème est réglé. C'est souvent un des points auxquels on ne pense pas, on se concentre, on est obsédé par les algos, les paramètres, mais de mon expérience, la difficulté c'est comment est-ce que quelque chose qui marche dans un environnement de test, ou en tout cas d'expérimentation, comment on fait pour qu'il marche dans un environnement de prod, de manière scalable, de manière sécurisée, de manière hautement disponible, on n'en a pas parlé, mais c'est une API, elle risque d'être appelée par votre appli mobile ou votre appli web ou un backend quelconque, il faut que ça marche. Sans avoir à recoder quoi que ce soit. Là, le déploiement, c'est un appel d'API. C'est un appel d'API et c'est tout. Donc voilà ce qu'on peut montrer rapidement sur Amazon ML. Alors juste pour finir, quelques motifs, par l'on français, d'architecture. Et on va essayer d'afficher plein écran, ça serait mieux. Voilà. Alors, vous vous souvenez, tout à l'heure, on a montré la vision globale du machine learning. Donc je voulais quand même repréciser ce que couvre Amazon ML. Alors, le cœur du service, c'est vraiment l'entraînement, l'évaluation... C'est ce qu'on vient de faire. On a des capacités limitées de visualisation de données. Je ne vous les ai pas montrées, mais on peut explorer un peu le dataset, on peut voir la distribution des données à l'intérieur du dataset, etc. On peut voir s'il y a des valeurs manquantes. Mais ça reste simple et sans doute insuffisant. Il faut sans doute des outils complémentaires pour bien comprendre son dataset. De mon point de vue, ça permet de faire un sanity check, de dire mes données, ce que je suis en train d'uploader là, ça a à peu près la bonne tête. Oui, c'est à peu près ce que je m'attendais à voir. Mais je pense qu'en amont, il faut aussi d'autres outils. Il faut d'autres outils de visualisation. Sur le feature engineering, on a quelques possibilités, mais là aussi, on n'a pas toute la richesse qu'on pourrait avoir. Je pense qu'on codait soi-même ou qu'on transformait soi-même ces données. Donc ça, mon conseil, c'est plutôt de le faire en amont, de le faire peut-être avec EMR, de le faire peut-être avec Redshift, en tout cas de transformer les données et de combiner les features ou d'extraire les features, mais en dehors d'Amazon ML qui fournit un support assez limité pour le faire. Bon, et puis pour le monitoring et le débit, on a du monitoring avec CloudWatch, comme sur tous les services AWS, et ça reste un monitoring plutôt orienté service et plutôt orienté infrastructure. Donc on n'a pas un monitoring très fin des prédictions, etc. On n'a pas l'équivalent d'un log détaillé de prédictions. Bon, maintenant, étant donné que le service est robuste, qui marche, etc., on n'a pas vraiment besoin d'aller débugger. Une fois que le modèle est déployé, vous voyez, il marche. Mais vraiment, une fois de plus, le cœur du service, c'est vraiment plutôt ces trois boîtes. Alors, je l'ai dit tout à l'heure, on peut faire des prédictions en mode batch. Donc un cas d'utilisation, ça pourrait être de dire, j'ai mes données brutes dans S3, j'ai mes logs, j'ai mon data lake, je vais l'ingérer dans EMR, je vais faire de l'agrégation, je vais joindre mes données, etc. Je vais remettre les données travaillées dans S3. Et puis là, je vais les ingérer dans Amazon ML qui va faire des prédictions, qui va repousser les résultats dans S3. Et puis, c'est là que mon application va venir les chercher. Donc, du batch, ça peut très bien convenir pour des applications qui n'ont pas de contraintes de latence particulière pour l'agrégation du back-office pur et dur. Voilà. Voilà un exemple d'utilisation avec Redshift. Donc on pourrait avoir des données qui sont structurées. Vous avez vos données clients, au moins ça, des données clients qui sont dans Redshift, que vous avez travaillées dans Redshift. Vous les ingérez dans Amazon ML, comme on l'a vu, puisque Redshift est une des sources possibles. Vous mettez vos prédictions dans S3. Vous pourriez les recharger dans Redshift, pourquoi pas. Et votre application, pourrait soit aller chercher les prédictions dans Redshift, soit aller les chercher dans S3. Là aussi, ça dépend un peu du cas d'usage. Mais je trouve que le contenu en Redshift et Amazon ML est assez intéressant. Parce qu'on peut vraiment avoir les données classiques de l'entreprise dans Redshift, aller en extraire une partie pour faire du prédictif, remettre les résultats de prédiction dans Redshift et puis continuer finalement de ne pas avoir à modifier l'application, ne pas avoir à aller chercher des prédictions directement dans Amazon ML. Alors on peut effectivement aussi, comme je vous l'ai montré, invoquer directement Amazon ML à partir d'une appli. Je vous ai montré comment le faire, c'est tout simple. Puis un autre cas auquel on pourrait penser, c'est de déclencher des appels prédictifs via des invocations de fonction lambda. Donc ici on a un exemple avec Amazon DynamoDB, donc il y a un feature de DynamoDB qui s'appelle DynamoDB Streams, qui permet d'invoquer une fonction lambda lorsque des écritures sont faites dans DynamoDB. Donc on pourrait dire, tiens, nouvelle écriture dans DynamoDB, je déclenche une lambda qui utilise ces données pour faire une prédiction avec Amazon ML, réécris le résultat dans DynamoDB, et puis mon application trouverait tout dans DynamoDB. La lambda peut aller elle aussi faire des prédictions. Et puis, on a bien sûr la solution de Predixis qui va aller au-delà de ce que sait faire Amazon ML en automatisant finalement beaucoup plus largement les opérations liées au machine learning. Alors je vous laisse en parler. Sylvain, tu veux commencer ? Oui. Avant peut-être de rentrer en tête d'automatisation, l'autre objectif de Predixis, c'est de répondre aux besoins des utilisateurs métiers, donc les chargés d'études marketing, les actuaires, qui vont avoir besoin d'écran de compréhension de ce qu'a trouvé la machine, l'intelligence artificielle, comprendre les drivers, ce qui explique un comportement d'achat, un comportement d'hôture, un comportement frauduleux, comprendre un niveau macro, mais aussi de le comprendre au niveau individuel. C'est-à-dire qu'est-ce qui explique le fait que pour telle personne, la machine considère qu'il y a un risque plus élevé d'avoir un comportement frauduleux. Quels sont les facteurs explicatifs pour chacun des individus ? Donc ça, c'est un des points globaux qui différencie Predixis et Amazon ML, c'est-à-dire les utilisateurs métiers. Et après, en termes de features complètement très machine learning, c'est effectivement la capacité aussi à travailler directement à partir de données structurées venant de plusieurs sources de données différentes. Donc cette fameuse partie en amont dans le cycle du machine learning qui n'est pas traitée par Amazon ML, comment est-ce que vous y répondez ? Finalement, en ayant une approche machine learning, mes utilisateurs ne voient pas, puisque le but c'est de faire un utilisateur de répondre à son problème de business et pas qu'il fasse du machine learning, on le fait pour lui. Donc il y a une approche machine learning qui consiste à explorer l'ensemble des possibles sources, de générer l'ensemble des possibles variables descriptives d'un comportement venant de ce que l'utilisateur fait sur le site web, des contacts que l'utilisateur a eu avec le centre d'appel, la manière dont l'utilisateur a réagi aux campagnes email qui lui ont été envoyées. À travers un algo, on va générer des signaux à partir de ces différentes sources et les évaluer avec une approche machine learning, comme tu disais tout à l'heure, régularisée, c'est-à-dire ne généralisant bien sur de nouvelles données. Donc en gros, pour qu'on comprenne bien, vous allez vous connecter aux différentes bases ou aux différents data warehouse de l'entreprise, vous allez aller piocher les tables qui contiennent potentiellement les bonnes infos. Et puis vous testez toutes les combinaisons. Vous allez tester toutes les combinaisons, vous allez trouver la combinaison de features venant de ces 50 bases et de ces 200 tables. Et vous allez trouver finalement automatiquement la bonne combinaison de features, celle qui va délivrer la meilleure, la plus grande valeur métier. Donc vous automatisez l'extraction des features et le feature engineering. C'est ça. Et qui après s'injecte dans un algo de machine learning tel que Amazon ML si tu veux, ou alors le nôtre, mais ça va préparer et donner de la richesse en amont, comme tu le montrais dans ton... Oui, donc c'est ça. Je continue à être un peu simpliste, mais le fameux CSV... À la limite, vous allez le fournir, il va être peut-être immensément complexe parce qu'il est issu d'une combinatoire très riche, mais finalement, je dirais l'utilisateur s'en fiche, parce qu'il n'a pas à le voir. Amazon ML, lui, va l'ingérer et va faire le modèle. Oui, complètement. Oui, c'est exactement ça. Ce qui fait gagner beaucoup de temps dans la partie préparation de données. Et c'est comme ça qu'on arrive, parce qu'à chaque fois que j'entends parler de vous, on parle en jours chez vous. On ne parle pas en mois, on parle en jours. On est allé chez le client, en deux jours on avait des résultats. Oui, complètement. Parce que le client va définir son problème business comme tu disais, et ça on n'y coupe pas. Et à partir de ce moment-là, il injecte à partir de son S3 actif, les données dans Predixis AI et Predixis AI va lui automatiser le travail et derrière il peut faire la prédiction avec Amazon Machine Learning ou Predixis suivant son souhait. Et donc ça va très très vite, c'est même une demi-journée pour avoir les résultats. Comme tu disais Sylvain, en fait, du coup vous pouvez parler aux métiers, vous parlez aux utilisateurs finaux, qui eux vont vous décrire leurs problèmes métiers, leurs problèmes business, et finalement vous raccourcissez complètement, vous compressez toute la phase d'analyse qui en temps normal peut prendre des semaines voire des mois, et qui chez vous devient effectivement une journée, deux journées, et donc vous leur donnez les réponses. En automatisant, j'allais dire la data science, pour dire les choses clairement, vous arrivez à leur fournir des résultats en deux jours. Et le métier peut valider la démarche parce que la machine lui présente des drivers, des causes qui lui parlent. Oui. Voilà. D'accord. C'est effectivement la même promesse que WSML, c'est-à-dire rapidement passer d'un Data Mart ou d'un Redshift ou d'un RDS au modèle que je vais pouvoir déployer et utiliser pour répondre à ma connaissance métier. Et pouvoir aller très vite sur une première solution intégrant un maximum de sources de données, donc le signaux explicatif du comportement. Voilà, et on l'a dit tout à l'heure, vous avez des clients dans le monde, on peut les reciter peut-être, pour les gens qui n'étaient pas là au premier OUNA ? Oui, on a Assurance, on a Banque Postale, Assure One, Assure People, Natixis, on a des clients dans l'industrie, on a des clients dans la finance aux États-Unis, enfin dans divers domaines. Alors comment, dernière question peut-être avant de répondre aux questions de nos auditeurs, comment est-ce qu'on teste ? C'est très facile, sur la marketplace, en trois clics et le produit se met dans le VPC du client et c'est un test justement qui permet directement et sans coût important de tester le machine learning. On est à des, c'est un peu comme Amazon, à des fractions du prix des approches classiques. Parce que le machine learning, ce que je dis, doit simplifier la vie du business et non pas la rendre plus complexe. C'est-à-dire, je ne connais pas. Non, ça doit servir au business et ça ne doit pas être coûteux. D'accord. Ok, donc si vous êtes client à AWS, vous allez dans la marketplace, AWS, vous cherchez Predixis, vous allez trouver l'AMI correspondante. Effectivement, dans quelques clics, vous allez la lancer. Vous testez pour 8 dollars de l'heure, c'est ça. Et puis, si ça vous plaît, très bien, continuez à vous en servir. Si ça ne vous plaît pas, vous arrêtez, ça vous aura coûté 8 dollars de l'heure. Puis n'hésitez pas à vous rapprocher des équipes de Predixis qui peuvent aussi vous aider à démarrer, à mettre en place et à aller plus loin dans votre recherche. Mais vraiment, je trouve que c'est un produit qui est super intéressant. Je n'aime pas faire de pitch profondément. Je le fais rarement, les gens qui me suivent sur les webinaires le savent, c'est vraiment exceptionnel. Là je le fais parce que vraiment vous comblez un manque et moi je l'ai vu marcher cette solution. Et effectivement c'est un accélérateur pour les projets de machine learning et un démystificateur de machine learning que je trouve extra. Voilà, donc j'encourage tout le monde à le tester et je précise je n'ai aucune action chez Predixis. C'est un client que je respecte comme tous les clients qui a une solution innovante et je pense qu'elle peut servir au plus grand nombre. Et c'est tout ce que je dirais là-dessus. Merci beaucoup. Voilà, quelques ressources pour finir. Donc les liens sur la page d'Amazon ML, le blog IAML de Machine Learning, donc le site de Predixis, et puis mon propre blog sur Medium, plutôt orienté Deep Learning, c'est un peu mon obsession du moment. Mais il faudrait que je me remette à faire un peu de Machine Learning. Je vais peut-être mettre des feuilles Excel, je vois que ça a du succès. Au lieu d'écrire du code Python, je vais peut-être me remettre à Excel. Et si ça aide les gens à comprendre le machine learning, c'est très bien, c'est tout ce que je demande. Voilà, merci beaucoup de nous avoir écoutés. Je vous remercie tout de suite de nous avoir rejoints aujourd'hui. Merci pour votre temps. C'était vraiment intéressant de nous avoir. Et nous allons répondre à vos questions. N'oubliez pas, oui pardon, le... N'oubliez pas le sondage. Donc de 1 à 5. 5, vous êtes très contents. 1, vous êtes mécontents. Et on va commencer à regarder les questions. Alors... Alors, il y a une série de questions sur Amazon ML. Pardon. Alors, un modèle généré est-il exportable hors AWS ? Alors ça, c'est une question qu'on me pose souvent et la réponse est non. Donc, c'est un service managé et le modèle doit être utilisé au sein d'Amazon ML. On parlera plus tard cette semaine d'un service qui est sorti à re-invent cette année, qui s'appelle Amazon SageMaker, qui est un autre service managé de machine learning et de deep learning, qui lui nécessite du développement, mais qui est beaucoup plus généraliste, on va dire, et beaucoup plus puissant qu'Amazon ML, et qui lui va permettre d'exporter les modèles. Donc sur Amazon ML, je vous l'ai dit, l'objectif est d'être simple, et d'être... C'est l'autoroute, d'accord ? Donc on a fait des hypothèses, on a vraiment voulu faire les choses simples. Donc il y a plusieurs questions sur quels types d'algos sont disponibles sur Amazon ML. Donc, je récapitule, il y a deux classes de problèmes qui sont adressables par Amazon ML. Donc, il y a la régression linéaire, c'est-à-dire la prédiction d'une valeur numérique. Et la classification. Soit une classification binaire, soit une classification multiclasse. Alors multi au sens supérieur à 2. Donc je vois les questions, est-ce qu'on a des réseaux de neurones, est-ce qu'on a des choses comme ça ? Non, Amazon ML c'est régression linéaire et régression logistique finalement. Ce qui sont les deux principaux cas de machine learning sur lesquels on tombe souvent dans les entreprises. Et donc pas d'autres résultats. En revanche, lorsqu'on parlera de SageMaker, on a beaucoup plus de choix, mais dans SageMaker, il faut écrire du code. On n'est plus tout à fait sur l'autoroute, on est sur la nationale. C'est une très belle nationale, c'est une belle quatre voies, mais de temps en temps, il y a des virages et il faut savoir les négocier. Alors oui, une question de Florian qui me dit, tu as dit qu'il y avait RDS comme source, mais on voit que S3 et Redshift. Alors effectivement, je n'ai pas dit Danry, la console, pour des raisons qui me dépassent, ne gère que S3 et Redshift. RDS est utilisable dans les API. C'est-à-dire que quand vous créez une data source avec les API d'AWS, vous pouvez utiliser RDS, ça n'a jamais été ajouté dans la console. Bon, je ne sais pas pourquoi, je suis désolé. C'est comme ça. Alors, qu'est-ce qu'on a d'autre ? Alors, une question de Vincent. Il me semble que AWS Glue est un service qui viendrait bien se coupler à Amazon ML. Est-ce que je me trompe ? Alors non, pas du tout. Glue, c'est un service d'ETL qui a été lancé à re-invent l'année dernière donc qui va vous permettre de créer un catalogue de données, de faire de l'extraction, de faire des transformations, de réingérer les données vers d'autres back-end, etc. Et effectivement, j'avais failli le montrer et j'ai pensé que j'aurais pas le temps et je me rends compte que j'ai eu raison parce que j'aurais pas eu le temps, mais c'est vrai que ça se marierait très bien. Le fait justement de faire les transformations de données, l'ETL en amont, de republier un résultat agrégé, consolidé dans S3 et de construire le modèle à partir de ces fichiers-là. Donc c'est une très bonne remarque. Effectivement, si vous avez des problématiques de transformation de données, multi-sources, multi-formats, etc., Glue est un service intéressant. Bonne question de Vincent. Alors, une question de Maxime. Au fur et à mesure que des données sont ajoutées dans la source, est-ce qu'on peut réexécuter le machine learning pour qu'il se profite ? Alors oui, tout à fait. Donc là, c'est tout à fait l'idée. C'est que, effectivement, vous allez tous les jours ou toutes les heures, vous allez continuer à écrire des données dans S3. Et donc, l'idée c'est d'automatiser ça, donc à chaque fois vous créez la data source à partir du fichier mis à jour, vous redéclenchez l'entraînement, vous republiez l'endpoint, etc. Donc oui, c'est un des points vraiment sympa dans Amazon ML, c'est que tout est basé sur des API. Et tout est basé sur des services qui sont simples, vous voyez, S3, entre S3, S3 et Amazon ML, il n'y a pas mille questions à se poser. Donc oui, l'automatisation du réentraînement est facile à faire. On pourrait même imaginer qu'on a une fonction lambda, puisqu'on peut programmer les fonctions lambda, on pourrait avoir une fonction lambda qui se déclenche toutes les 24 heures et qui redéclenche l'entraînement via les API, etc. Donc l'idée c'est évidemment que tout ça marche toujours. Alors qu'est-ce qu'on... Alors il y a une question de Vincent. Comment est-ce qu'un client peut avoir un accompagnement concernant la réflexion d'un concept d'utilisation de machine learning pour son business ? Bah écoutez, je pense qu'à côté, à ma droite et à ma gauche, j'ai les bonnes personnes. Donc je pense que si vous contactez Predixis, ils vont vous aider à démarrer, c'est des geeks mais ils font du conseil aussi, ils peuvent vous aider. Une dernière, une dernière Hugo, allez, une dernière. Une dernière, c'est toujours dur sur les regards parce qu'elles sont toutes bien. Alors, y a-t-il moyen de tester gratuitement Amazon Machine Learning ? Je crois bien que oui. Alors, on va tester ça. On va regarder tout de suite. Donc, il me semble que le service fait partie du FreeTier. Ah, c'est sympa les pages en allemand. Est-ce que j'ai dit une bêtise ? J'étais convaincu qu'on était dans le fruitier avec Amazon et même. Tout le monde parle allemand bien sûr. On va voir, j'ai peut-être dit une bêtise. Pour ceux qui ne savent pas ce que c'est que le free tier, c'est un niveau d'usage gratuit dans les 12 mois qui suivent la création de votre compte. Pendant les 12 mois qui suivent la création du compte, vous pouvez utiliser tous les services qui sont ici gratuitement, dans les limites indiquées évidemment. Et j'étais à peu près sûr qu'il y avait Amazon Machine Learning, mais si j'ai dit une bêtise alors, ce ne sera pas la première fois. Non, il n'y a pas. Il y a été à une époque, j'en suis sûr. Il n'y est plus. Je suis désolé. Donc c'était une bonne question puisque je ne connaissais pas la réponse. Merci. Non, donc non, désolé. Amazon ML n'est pas dans le free tier. Ceci étant dit, le coût d'usage du service est vraiment, vraiment faible. Vous voyez l'entraînement, on parle de 42 cents par heure d'entraînement. Si vous entraînez pendant 10 minutes, comme on l'a fait là, ça coûte 4 cents. Et puis après, sur les prédictions, c'est 1 cent pour 1000 prédictions. Il y a moyen de le tester à moins d'un dollar. Après, faites attention, ne déclenchez pas 10 millions de prédictions. Mais le test est effectivement peu coûteux. Désolé, pas de test gratuit sur Amazon ML. Mais c'était une bonne question. Hugo me fait les gros yeux, je crois qu'on a fini. Qu'est-ce que j'oublie ? Rien. Merci beaucoup, de nous avoir suivi aujourd'hui. J'espère que vous serez au rendez-vous demain. Vous avez le programme, puisque j'ai vu une question là-dessus. Vous avez la liste des événements, si j'arrive à les retrouver, qui est en ligne. Et vous avez le programme de la semaine. Donc si vous voulez voir le programme des autres webinars, vous le trouverez sur le site. Vous allez sur aws.amazon.com.fr.events Vous avez dû y aller pour vous inscrire. Et là, vous avez le détail. Demain, on parlera d'AdooT, de MR, de Spark. On va essayer de faire des démos autour de ça. Spark, Machine Learning, etc. Mercredi on commencera à aborder le deep learning, jeudi on se concentrera sur de la reconnaissance d'image et d'autres sujets, et j'amènerai des gadgets donc voilà, ratez pas ça et vendredi on parlera des nouveautés annoncées à re:Invent et dieu sait qu'il y en a eu et on zoomera beaucoup beaucoup sur SageMaker qui est certainement le service le plus attendu. Merci beaucoup. Je vous souhaite une très bonne soirée. Merci encore à Jean-Louis et à Sylvain de Predixis. Merci. Et donc rendez-vous demain pour deux autres webinars et bonne soirée.