Webinar Salon du Big Data 2016 Simplifiez le Big Data avec AWS

Transcript

Très bien, on va commencer. Je suis Julien Simon, je suis évangéliste technique chez AWS. Aujourd'hui, je vais vous parler d'un sujet qui, j'imagine, intéresse tout le monde, qui est le Big Data. Très précisément, je vais vous expliquer comment simplifier votre vision et votre approche du Big Data sur la base d'un modèle tout simple en quelques étapes. Et je vais illustrer ce modèle à l'aide de différentes technologies qui sont disponibles sur AWS, de différents cas clients qui utilisent ces technologies. Et à la fin de la présentation, je vous montrerai quelques architectures de référence pour implémenter vos projets principaux. Le Big Data, tout le monde le sait, c'est un vaste sujet, un nombre immense de technologies, un nombre immense de fournisseurs, et on peut très facilement se perdre dans cette complexité. Ce que nous voyons chez nos clients qui réussissent à implémenter des projets Big Data, c'est un découpage en quatre étapes, en quatre phases que nous avons détaillées pendant la présentation. La première phase, qui est souvent la plus compliquée, est la phase d'ingestion des données, de collecte, où on va récupérer toutes les données qui doivent être intégrées dans l'analyse. La deuxième étape est l'étape de stockage, qui peut être plus ou moins compliquée en fonction du volume de données qu'on doit stocker. La troisième étape est une étape de processus, d'analyse des données, et qui va d'ailleurs itérer, puisqu'on va certainement transformer les données un certain nombre de fois, les stocker sous cette forme intermédiaire, puis les réanalyser jusqu'à obtenir la forme voulue. Et enfin, on va consommer ou visualiser ces données pour en extraire les insights, les informations métiers dont on a besoin. Ce qui caractérise ce processus, c'est, de notre point de vue et du point de vue noté en trois choses, le temps qu'il faut pour obtenir une réponse entre l'ingestion des données et la visualisation, c'est le débit de ces processus, quel volume de données est-ce que vous pouvez traiter en un temps donné, et puis bien sûr le coût, puisque l'ingestion, le stockage, l'analyse de ces données nécessitent de l'infrastructure, des ressources, et on souhaite le faire de manière économique. Commençons par la première étape qui est la phase de collecte. La complexité de la collecte, c'est que, si vous faites déjà des projets Big Data, le format des données va être extrêmement variable. Dans la fameuse définition du Big Data des 3 V, on a un des V qui veut dire variété. Et donc on va retrouver cette variété de formats. Le plus connu, c'est le format transactionnel où on va récupérer des données qui vont provenir d'applications web ou d'applications mobiles et qu'on va stocker dans des bases de données, voire dans des caches. On va aussi avoir des informations qui relèvent de la recherche, qui peuvent être des moteurs de recherche, qui peuvent être de la recherche dans des blogs, et donc là on a de l'information qui est beaucoup moins structurée et qui arrive un petit peu plus en forme de flux. On peut avoir des fichiers, dans le monde, en particulier le monde du web, on va être très friands de stockage, d'ingestion de logs web, de logs de navigation qu'on va exploiter pour en extraire de la valeur. Et puis, plus récemment, on commence à voir des données qui viennent de flux type IoT, Internet of Things, qui vont être des flux probablement 24/7, d'extrêmement petite taille, mais en extrêmement grande quantité. Et donc, on va être confronté à la complexité de stocker des données transactionnelles, d'ingérer des données de recherche, d'ingérer des fichiers et d'ingérer des flux de données. Ces données viennent forcément de systèmes hétérogènes, venant de vos clients, de vos partenaires, d'internautes, etc. Donc là, on va devoir se préparer à stocker tout ça dans des systèmes adaptés. Donc parlons de la phase de stockage. Dans la phase de stockage, comme je l'ai dit, on va devoir s'adapter à la variété des formats et à la granularité des données. Si on commence par les données les plus granulaires, donc les données de type flux qui vont venir par exemple de capteurs connectés, on pourrait les stocker dans différents systèmes d'AWS comme par exemple DynamoDB, qui est notre base de données managée NoSQL. DynamoDB est une base de données extrêmement scalable. Je peux vous citer un client qui s'appelle Adroll, qui est un des leaders mondiaux de la publicité ciblée, qui opère plus de 10 000 annonceurs dans une centaine de pays, et qui stocke des milliards d'événements par jour dans DynamoDB. Donc voilà, de manière extrêmement scalable et performante. On pourrait également considérer Kinesis, qui est un système de fil de messages persisté, donc il va stocker les messages pendant une durée déterminée pour qu'ils soient consommés ensuite. Kinesis, vous l'utilisez certainement indirectement sans le savoir. Si vous jouez à Clash of Clans, si vous jouez à Boom Beach, si vous jouez à tous ces jeux qui sont édités par Supercell en Finlande, sachez qu'ils s'appuient sur une architecture Kinesis qui stocke 45 milliards d'événements par jour. Vous pourriez également utiliser Kafka, qui est un système de messagerie open source, un projet intéressant. Pour la partie fichier, qui vient de web ou d'applications, vous avez là aussi plusieurs possibilités. Si vous travaillez dans les environnements Hadoop, Spark, etc., vous pouvez évidemment les stocker dans HDFS, qui est le système de fichiers utilisé par Hadoop. Vous pouvez également les stocker dans Amazon S3, qui est le stockage d'objets d'AWS. Et vous pouvez les archiver dans Amazon Glacier, qui est un archivage long terme, extrêmement durable et extrêmement économique. Je peux vous citer le cas de SoundCloud, la société allemande qui travaille dans le monde de la musique, et qui stocke 2,5 pétaoctets dans S3. Tous les morceaux de musique qui sont gérés par SoundCloud sont stockés dans S3. Donc 2,5 pétaoctets, et ils sont également backupés dans Glacier. Au total, 5 pétaoctets de données stockées de manière durable dans ces systèmes. Pour la partie search et database, là on va devoir stocker des données de plus petite taille, des données plus structurées, des transactions, des choses comme ça. Et là on a une panoplie de technologies. On pourrait à nouveau utiliser DynamoDB si on veut bénéficier d'une base de données NoSQL qui n'impose pas de schéma. Si on veut une base de données structurée, transactionnelle, à ce moment-là on peut se tourner vers Amazon RDS, qui est notre base de données managée qui fonctionne avec les moteurs MySQL, MariaDB, PostgreSQL, SQL Server et Oracle. Il y a aujourd'hui plus de 100 000 clients actifs chez AWS sur RDS, un service extrêmement populaire. Et si vous avez besoin d'un système particulièrement scalable, vous pouvez vous tourner vers Aurora, qui est compatible avec MySQL mais qui offre un stockage scalable de quelques gigas jusqu'à 64 téraoctets sans modification de l'instance. Aurora est utilisé notamment par Alfresco, la société de gestion de contenu, qui stocke un milliard de documents dans Aurora et qui a rapporté un niveau de performance dix fois supérieur à des solutions traditionnelles. Ces données qui sont moins structurées, vous pouvez envisager de les stocker par exemple dans ElastiCache, qui est notre cache managé, qui permet d'utiliser le même cache ou Redis, ou alors dans Amazon Elasticsearch, qui est notre service managé d'Elasticsearch. Un point important et que je veux vraiment souligner, et une erreur qu'on peut voir encore malheureusement ici et là, c'est de penser que ce stockage de bases de données et search peut être fait dans un unique système. Malheureusement, on voit encore des gens qui décident d'empiler tout ça dans une unique base de données pour des raisons de licence, pour des raisons qui les regardent, des raisons complexes. Ce ne sont pas toujours techniques, malheureusement. Et donc, ils vont essayer de construire cette espèce de couteau suisse qui est très important, mais qui est totalement inutilisable. À force de vouloir tout faire, on ne peut pas le prendre en main et en fait on ne peut utiliser aucun de ces outils. Notre recommandation et ce que nos clients appliquent et mettent en œuvre avec succès, c'est vraiment de choisir un data store qui est spécialisé pour le type de données qu'on veut utiliser. On va trouver différents critères. Je ne vais pas, rassurez-vous, détailler tout ce slide. Vous pourrez le parcourir ensuite. Mais voilà, on va avoir des critères comme la latence, le volume de données à stocker, la taille des données à stocker, le taux de requête par seconde qu'on va faire sur les données, le coût du stockage, etc. Et donc, en fonction de la température de vos données, la température, c'est une combinaison de la vitesse d'accès, de la fréquence d'accès, etc. On peut aller de, par exemple, ElastiCache, DynamoDB, qui vont stocker des items extrêmement granulaires, avec un taux de requête extrêmement élevé, jusqu'à des systèmes comme S3 ou Glacier, qui eux vont avoir une latence supérieure, mais vont être à peu près sans limite en termes de capacité de stockage, vont dépasser très largement le pétaoctet, le tout à un coût extrêmement économique. Ce qui est important, c'est de comprendre la nature de vos données et de les stocker dans le système qui va vous offrir le meilleur ratio prix-performance, en tenant compte également de l'escalabilité. Surtout, de ne pas essayer de tout tasser dans un unique système qui vous offrira finalement le plus petit dénominateur commun. Donc une fois que vous avez fait le choix de stockage, on peut maintenant considérer la partie processing. La partie processing, là aussi, je dirais de la même manière, elle va devoir s'adapter au format de vos données. Si vous avez des données de type flux, vous allez certainement vous orienter vers des technologies extrêmement interactives, extrêmement réactives, comme Kinesis, que j'ai déjà cité, qui est capable de stocker ces données, de les persister, mais aussi de les traiter en mode flux, donc en temps réel. Vous pourriez également considérer AWS Lambda, qui est une technologie récente chez AWS, qui est une technologie qu'on appelle serverless, puisque là, on ne gère plus aucune instance de serveur, on se contente d'uploader les fonctions qui vont manipuler des données et qui vont être totalement managées par AWS. Je peux citer le cas d'un gros retailer américain, qui s'appelle Nordstrom, que vous connaissez nécessairement si vous avez voyagé aux États-Unis, qui a bâti pour son site web un moteur de recommandation de produits pour ses internautes à l'aide de Lambda. Si vous avez plutôt envie de travailler en mode batch, vous avez la possibilité d'utiliser les technologies habituelles du monde Hadoop au sein d'Amazon Elastic MapReduce (EMR), qui est notre service Hadoop managé, qui est utilisé depuis des années par Yelp aux États-Unis. Yelp, qui est un site web là aussi très connu qui fournit des avis de consommateurs sur des businesses locaux, fait tourner environ 250 jobs MapReduce par jour et gère à peu près 30 téraoctets de données quotidiennement. C'est un exemple parmi littéralement des dizaines d'autres. Et donc là, vous pourriez utiliser les différentes technologies comme Pig, Hive. Vous pourriez évidemment développer des jobs MapReduce en Java. Vous pourriez utiliser Spark, etc. Et puis sur le haut de la stack, si vous avez envie d'avoir une approche plus interactive, une exploration plus interactive de vos données, là vous allez vous orienter vers des technologies, donc là aussi peut-être vers Spark ou vers Impala, qui sont disponibles en EMR. Si vous êtes plus à l'aise dans un monde SQL, il est probable que vous utilisiez Amazon Redshift, qui est notre Data Warehouse managé, qui rencontre un grand succès. Il est notamment utilisé par le Financial Times pour faire l'analyse en temps réel de la lecture des articles par les internautes. Il est utilisé massivement par NTT, l'opérateur télécom japonais qui opère des data warehouses de plusieurs pétaoctets. Et puis plus près de chez nous, il est utilisé en France par la société Photobox, que vous connaissez probablement, qui gère sa CRM, toutes ses campagnes, qui fait toute son analyse de trafic aussi avec Redshift, et qui au passage a divisé son coût par 7 par rapport à la solution précédente. Et puis tout en haut, vous pourriez décider de faire du machine learning, de faire de la prédiction, d'utiliser ces données pour prédire des paniers moyens, prédire des comportements d'utilisateurs, que sais-je, on peut prédire tout un tas de choses. Et donc on a là aussi un produit qui s'appelle Amazon ML, qui est un service managé ultra simple, qui rend vraiment le machine learning extrêmement simple, extrêmement démocratique, et qui est totalement accessible aux non-experts, et qui permet en quelques heures de bâtir des modèles, de les mettre en production, et de rendre vos applications intelligentes. Donc, là, quelques exemples de technologies supplémentaires, j'ai déjà à peu près tout cité sur la partie analyse. Soit du stream, soit du batch, soit de l'interactif, soit du machine learning, tout ça est disponible, en particulier tout l'écosystème Hadoop est intégralement disponible dans EMR, en ayant évidemment la satisfaction de ne pas avoir à gérer de cluster, de ne pas avoir à faire de DOPS sur ces systèmes particulièrement complexes et de se concentrer uniquement sur l'extraction de valeur des données. Donc là aussi, le choix est porté sur des critères comme la latence, la durabilité, le volume de données. Si vous avez envie de faire du SQL, vous allez plutôt tourner du SQL à grande échelle, vous allez plutôt vous tourner vers Redshift. Si vous avez envie d'avoir une latence encore plus faible et des jobs automatiques de production, vous allez plutôt vous tourner vers Spark. Et puis si vous avez envie d'être un peu entre les deux, vous pourrez sans doute faire du live. Ce cycle de stockage et de processing va tourner, va itérer jusqu'à ce que vous obteniez des résultats et une fois que vous les aurez obtenus, vous aurez envie de les consommer et de les visualiser. Et là, je dirais de manière un peu symétrique à la phase de collecte, vous allez exporter ces données vers vos outils préférés de visualisation, qui peuvent être des outils plutôt R&D, plutôt Data Scientist, comme RStudio, comme IPython, comme Zeppelin, qui vont être finalement des outils d'analyse et d'exploration encore plus poussée sur vos données. Ou alors, vous aurez envie de bâtir des dashboards et d'exposer vos résultats aux utilisateurs métiers, à votre direction générale, etc. Et là, vous pouvez connecter Kibana, vous pouvez connecter MicroStrategy, vous pouvez connecter Tableau, qui a été mentionné tout à l'heure. Tout ça marche nativement avec les systèmes dont on a parlé précédemment. Je tiens à mentionner un produit qu'on est en train de sortir, qui a été annoncé à re:Invent, notre conférence technique en octobre, qui s'appelle QuickSight, qui est un outil de visualisation in-memory, temps réel, encore en preview pour l'instant, qui n'est pas disponible à l'heure généralement pour tous les clients. Ça arrivera prochainement et vous pouvez aller voir les vidéos de re:Invent sur YouTube pour une petite démo de ce produit, c'est extrêmement intéressant. Je pense que les clients l'adopteront très rapidement, vous verrez la flexibilité et la rapidité qu'il peut procurer. Sur la phase de visualisation, c'est ce que j'ai dit, on va avoir des outils plutôt pour le métier, plus de dashboards, on va avoir des outils peut-être plus orientés vers les data scientists, ou alors, carrément, des applications, on peut exporter via des API ces données et les retraiter, les représenter dans vos propres applications. Si on essaie de résumer tout ça, ça donne ce magnifique slide. Les quatre grandes étapes, la collecte, le stockage, l'analyse, la consommation, avec la phase de collecte extrêmement diversifiée, finalement, c'est ce que vous ne maîtrisez pas du tout, ce sont les données que vous impose le monde extérieur, que vous intéresse, des applications, le mobile, vos partenaires, vos clients, vos fournisseurs de données. Une phase de stockage qui doit être mûrement réfléchie et spécialisée en fonction des données que vous voulez stocker. J'insiste vraiment là-dessus. One size does not fit all, comme on dit. Idem pour l'analyse, en fonction de ce que vous voulez faire des données, vous devez adopter sans doute différents systèmes. Ne croyez pas qu'un seul système d'analyse va tout faire. Dans certains cas, il vous faut des systèmes compatibles avec SQL. Dans certains cas, il vous faut des systèmes plutôt dans le monde Hadoop. Et dans d'autres cas, il va falloir des choses un petit peu plus innovantes, un petit peu plus radicales comme Kinesis ou Lambda. Il faut vraiment faire un panorama et bien choisir. Et puis, la phase de consommation, où là aussi, vous allez avoir sans doute une grande diversité d'outils en fonction des populations auxquelles vous exposez vos données. Alors, pour conclure, je voudrais vous présenter deux ou trois architectures de référence, où je pense que vous allez reconnaître certains de vos projets. Le premier cas, architecture de référence dont je voudrais parler, c'est celle-ci. C'est l'architecture interactive et batch, qui est généralement le premier niveau d'adoption Big Data, où on va avoir des sources de données, on va les stocker dans S3, généralement. Et puis ensuite, on va avoir deux couches qui vont fonctionner en parallèle. Une couche batch qui va faire du gros traitement de données, ça peut être de l'agrégation de logs web, ça peut être de l'ETL, ça peut être des choses comme ça. Là, il va falloir de la grosse machinerie où on n'a pas besoin de temps réel, mais par contre, on a besoin de beaucoup de stockage, on a besoin de beaucoup de puissance de calcul. Et là, tout naturellement, on va se tourner vers EMR pour pouvoir créer des clusters, les scaler et puis surtout les arrêter quand on a fini, ou en tout cas les redimensionner quand on a terminé de travailler pour arrêter de payer tout ça. Il y a aussi des grandes forces d'AWS, le paiement à l'usage. S'il vous faut 100 nœuds pendant 2 heures, vous les lancez et puis quand vous n'en avez plus besoin, vous pouvez redescendre à 10 ou même à 0 et vous ne payez plus rien. Et puis voilà, une fois que ce travail est terminé, vous exportez vos données vers le consommateur. Et donc en parallèle, vous pouvez avoir une couche interactive qui va par exemple vous faire des statistiques, vous avez envie d'explorer un petit peu, pas forcément en temps réel, mais en tout cas de manière interactive, ce qui se passe sur vos données. Et là, vous pourriez le faire avec EMR, en utilisant des technologies un peu plus réactives comme Impala ou Spark. Mais vous pouvez aussi le faire avec Redshift. Je recommande à tout le monde de ne pas se précipiter systématiquement sur MapReduce ou sur Spark. Redshift peut tout à fait répondre à ce genre de besoin, y compris à une échelle extrêmement importante. Donc voilà une première architecture assez simple dans laquelle on peut envisager éventuellement de mettre du machine learning au milieu si on a ce besoin de prédiction. La deuxième étape, une fois qu'on a fait ça, généralement on se dit c'est super, ça marche, maintenant on veut tout en temps réel. On veut à la fois les données de production, on veut tout en temps réel. Donc là, on va faire les sources de données et on va devoir se tourner vers des briques de stockage et de processing un peu différentes. Donc on pourrait se tourner vers Kinesis ou DynamoDB Streams, par exemple, pour streamer les données, les persister et les amener à une brique de processing. Cette brique de processing pouvant être, par exemple, Spark ou Storm. Ça pourrait être une application que vous avez développée et qui utilise la Kinesis Client Library, une application maison. Et ça pourrait également être Lambda, qui est totalement adapté à ce genre de situation, où vous pourriez déclencher l'appel à des fonctions Lambda à chaque fois que des données se présentent à la sortie de Kinesis ou à la sortie du DynamoDB. Et puis ensuite, vous pourriez pousser les résultats de ces traitements, soit dans un cache, soit dans DynamoDB, soit pourquoi pas dans une base de données relationnelle comme RDS, pour être visualisé par vos outils. Et vous pourriez également vous servir de SNS pour avoir des notifications en cas d'alerte. Si votre site e-commerce ne reçoit plus aucune commande depuis 5 minutes ou si votre partenaire de paiement ne fonctionne plus depuis 5 minutes, je pense que vous avez envie de le savoir en temps réel et pas dans le dashboard du lendemain matin. Et donc, vous pourriez déclarer des alertes via SNS, qui est notre système de notification. Et puis, dernière architecture, l'architecture lambda qui est la plus réactive, la plus pointue, sans doute la plus complète aussi, où là, toutes vos données seules en Kinesis, et vous auriez plusieurs couches de fonctionnement, donc une couche qui pourrait faire du batch, qui pourrait déstocker vos données dans S3, les envoyer dans EMR pour faire du heavy lifting et pour faire de la grosse agrégation. Et puis vous pourriez aussi l'envoyer dans une couche plus rapide comme Lambda ou comme Kinesis et puis ensuite les pousser dans un cache. Voilà, tout ça sont vraiment des étapes typiques qu'on voit chez nos clients. Il faut se laisser le temps de comprendre ces technologies, de les adopter, et puis surtout de choisir les technologies les plus cohérentes pour vos use cases, et d'éviter à tout prix l'over-engineering, qui est souvent un problème dans les projets Big Data. Donc faites simple, c'est simple, et puis mesurez et perfectionnez ensuite. Si on résume vraiment les trois messages que je souhaite vous faire passer aujourd'hui, c'est... je vais le répéter une dernière fois, d'utiliser le bon outil pour le job. Choisissez le bon système de stockage, choisissez le bon système d'analyse, comprenez bien la nature de vos données, comprenez bien comment vous y accédez, quel niveau de latence, quel débit vous attendez, et les réponses devraient se présenter assez aisément. Faites jouer à fond l'effet service managé, laissez-nous nous occuper de la plomberie, vous n'avez pas envie de gérer les clusters Hadoop, vous n'avez pas envie de gérer les clusters Kinesis, vous n'avez pas envie de faire ça, c'est compliqué, c'est lourd, les scénarios de panne sont compliqués, donc laissez-nous faire l'administration, laissez-nous être les meilleurs DBA que vous n'avez jamais eus, laissez-nous être les meilleurs administrateurs Hadoop que vous n'avez jamais eus, et concentrez-vous sur votre projet et sur l'extraction de la valeur. Et puis surtout, regardez bien combien vous coûtent vos projets. Une fois de plus, l'avantage d'AWS, c'est du paiement à l'usage. Il n'y a pas de gros chèques à faire pour commencer un projet. Vous pouvez commencer un projet pour des sommes dérisoires, scaler quand c'est nécessaire, éteindre les clusters quand c'est nécessaire et minimiser votre dépense sur l'infrastructure. Voilà, j'en ai terminé, je vous remercie beaucoup de m'avoir écouté. Je vous donne rendez-vous le 7 et le 8 au salon du Big Data, où nous aurons un stand. Nous aurons également deux sessions le 8 mars, une à 14h sur IoT et Big Data, et une à 15h30 sur Redshift, que j'aurai le plaisir d'animer, j'espère vous voir nombreux. Si vous souhaitez en savoir plus sur AWS, je vous donne également rendez-vous le 16 mars au Awesome Day, c'est une session de formation qui aura lieu à Paris, qui est gratuite, qui se remplit vite, donc ne tardez pas à vous inscrire. Vous pouvez également noter dans vos agendas la date du 31 mai, qui est le Summit Amazon à Paris, qui est notre conférence technique annuelle en France, avec énormément de contenu et la présence du CTO d'Amazon en keynote. C'est toujours un grand moment à écouter. Si vous souhaitez en savoir encore plus, je vous invite à rejoindre nos usergroups. On a des usergroups à Paris, Lyon, Nantes, Lille et Rennes pour l'instant. Ils sont tous visibles sur meetup.com. Je pense que vous les trouverez facilement. Nous serons également présents à d'autres événements qui sont sur ce slide, donc IoT World, six autres événements dans le monde de l'IoT, et donc deux conférences plutôt orientées développeurs, DevOps et TopScale à Paris au mois d'avril. Et si vous voulez vraiment être parfaitement courant de tout ce qui se passe chez AWS en France, la meilleure façon de le faire, c'est de nous suivre sur Twitter, soit AWS Actu, le feed officiel, soit Julien Simon, qui est mon Twitter personnel et qui va relayer tous ces événements. Et enfin, nous avons un groupe de communauté sur Facebook pour regrouper les développeurs et les utilisateurs d'AWS en France. Et vous êtes tous les bienvenus. Voilà, je vous ai inclus sur ce dernier slide les références clients que j'ai mentionnées pendant la présentation, donc les Supercell et autres Soundcloud. Il y a également un white paper qui a été mis à jour récemment, qui est tout à fait à jour avec ce que j'ai expliqué aujourd'hui, sur l'offre Big Data d'AWS. Et puis, nous avons également un blog, le blog Big Data, qui est extrêmement actif et où vous aurez toutes les dernières informations sur tous les derniers services AWS en matière de Big Data. Je vous partage la présentation si j'arrive à le faire. Vous avez le petit lien sur le PDF qui s'est affiché. Si jamais, pour une raison quelconque, vous n'arrivez pas à le télécharger, n'hésitez pas à me contacter sur Twitter et je serai ravi de le repartager. Je vous remercie beaucoup d'avoir fini la journée en m'écoutant et en me consacrant une demi-heure. Si vous avez quelques questions, je serai ravi d'y répondre. Une fois de plus, n'hésitez pas à venir nous voir sur le stand les 7 et 8, ainsi qu'une partie de l'équipe AWS France. Ils feront de leur mieux pour répondre à toutes vos questions. Merci beaucoup, j'attends vos questions et je vous souhaite une bonne soirée.