Sopra Steria utilise des cookies et autres traceurs afin d'améliorer votre expérience utilisateur, réaliser des statistiques de visites, vous proposer des services et offres adaptées à vos centres d'intérêt, sécuriser le site internet et nos échanges et vous permettre de partager des informations sur les réseaux sociaux et avec nos partenaires. Nous conservons votre choix pendant 6 mois. Vous pouvez gérer vos préférences cookies en modifiant vos paramètres à tout moment en cliquant sur Gestion de vos cookies
En savoir plus sur nos politiques de confidentialité
Retrouvez tous nos événements à venir sur la page dédiée "Rencontrons-nous".
Comment Sopra Steria met l’innovation et la technologie au service de ses clients ?
Isabelle Messins, responsable relations École et marque employeur du pôle France Sopra Steria.
Charles Eric GiraultAlors la valeur ajoutée c’est qu’il s’agit d’un outil réservé à un public d'administrations. L'administrateur du produit pourra créer les comptes et connecter des applications. On a développé des plugins pour offrir des fonctionnalités supplémentaires à des créateurs classiques. InnerAuth permet de gérer de manière fine des clients OpenID Connect par les propriétaires eux-mêmes. Les gestionnaires seront les propriétaires des clés d’API construites, et de ce fait, ils pourront administrer directement leurs clients sans avoir besoin de demander l’accès à un administrateur. Donc ça c'est vraiment une première. En clair, InnerAuth permet d’avoir moins de choses à gérer. On délégue la partie authentification à une équipe qui s'occupe très bien de ça, en l'occurrence InnerAuth.
Et donc, n’importe quel utilisateur qui en fera la demande pourra connecter son application à InnerAuth ?
Charles Eric GiraultAlors on va le voir dans quelques instants. Tout utilisateur de Sopra Steria peut utiliser InnerAuth pour ses propres besoins. Je reviens un peu en arrière, pour répondre à la question par rapport aux alternatives qu'on aurait pu étudier. On avait regardé un peu du côté de Hydra qui est une solution beaucoup plus légère, mais KeyCloak c’était vraiment la solution qui répondait le plus à nos besoins en termes d’IHM et de facilité de déploiement sur sur nos environnement.
Charles Eric GiraultPar rapport aux plugins du coup qu'on a été amenés à faire. Donc comme je le disais, la gestion fine des clients par les propriétaires eux-mêmes, la possibilité de restreindre l'authentification sur une application. Donc imaginon qu’on délègue l’authentification à France Connect. Ce serait France Connect qui nous dirait à quelles administrations on ne peut pas se connecter. Pour le blocage de la connexion, un plugin est nécessaire. Et donc, nous c’est ce qu’on a fait. On a développé les plugins pour restreindre les droits utilisateurs si besoin. Pour ce faire, on a développé un script shell qui va automatiser la création de ce client en respectant les bonnes pratiques. Et cela permet d’éviter les erreurs humaines. Dans cette slide, on peut voir les captures d'écran de notre application InnerAuth.Donc on voit bien la page de connexion. L’utilisateur va pouvoir choisir avec quel provider il s’authentifie. La deuxième petite capture d'écran sur la droite est donc anonymisée et on voit des clés d’API. Donc on voit que là j'en avais cinq et on va pouvoir éditer le client pour modifier les différentes propriétés. Par exemple, dans l'écran en bas à gauche j'ai ouvert “Edition du client” et je me suis mis sur la page de création de modification des rôles associés à ce client. Et puis sur la troisième capture d'écran on voit comment associer un rôle à un utilisateur. Donc là, je suis toujours avec mon compte et je me suis mis sur un utilisateur et je regarde les droits qu'il a. On va reprendre le type d'activité qu'on peut avoir sur ce type de projet et ça répondra à ta question Isabelle de tout à l'heure sur le processus pour demander un nouveau client dans l'application.Nous voulions faire en sorte que ça soit le plus fluide possible et le plus automatisé possible. Donc pour cela, on a développé un formulaire Microsoft qui va demander un certain nombre de champs, dont le nom du projet, la clé d’enregistrement pour avoir un nom préférentiel, l’urgence de la demande. Dès que l’utilisateur va soumettre son formulaire, toute l'équipe aura une notification. On a utilisé le processus Microsoft Flux pour faire cela et toute l'équipe est notifiée automatiquement. De là, on va lancer le script pour créer le client. Donc dernier petit point sur les types d'activités. Pour revenir sur les aspects DevOps, on utilise notre fameux système interne proposé par la Digital Platform. Donc là, j'ai mis une capture d'écran du plan de construction de notre produit qui est créé à chaque fois qu'on fait une modification. A savoir que tous ces tous ces traitements là que vous voyez, je n'ai pas eu à les paramétrer.C'est directement la DEP qui a proposé ce template par défaut. Donc je n'ai rien eu à faire.
Isabelle MessinsD’accord. J'ai une question d'Hélène pour toi. Avec toutes ces données sur ces plateformes, si on les croise, est ce qu'il serait possible de les détourner vers un projet assurance par exemple ?Charles Eric GiraultAlors InnerAuth c'est vraiment agnostique car il n'y a pas de domaines métier derrière le concept. On peut donc le relier à n'importe quel type de projet. On peut le relier à des projets d'assurance ou autre. Je ne sais pas si ça répond à la question.
Isabelle MessinsDonc c'est vraiment en interne. Mais est ce que c'est quelque chose qu'on pourrait déplacer aujourd'hui dans d'autres sociétés ?
Charles Eric GiraultTout à fait. Oui. D'autres sociétés utilisent InnerAuth, j'imagine de façon relativement similaire. C’est produit très connu,
Isabelle MessinsMerci, je te laisse conclure.
Isabelle MessinsJe te remercie beaucoup Charles Eric. Dernière question, quels sont les protocoles d’authentification ?
Charles Eric GiraultOn supporte OpenID Connect et SAML pour l'authentification sur la plateforme. Après, on peut imaginer les étendre à d'autres choses avec un plugin. Isabelle Messins
Merci, encore une dernière question qu’on nous a posé. Y a t il une réflexion sur un cas d'usage en fédération d'identités avec plusieurs annuaires d'entreprises ?
Charles Eric GiraultOn a commencé à modifier des réflexions pour pouvoir connecter d'autres sources utilisateurs. C'est un sujet qui est un cas à l’étude, et pour des raisons de sécurité ça prend un peu de temps. Donc on a pas mal de réflexions là-dessus. Mais c'est bien un sujet qui est en cours.
Isabelle MessinsEt les données sont sous quel format ?
Charles Eric GiraultC'est de l'API ultra classique au format Json.
Luc Langevin, architecte chez Sopra SteriaOK et de manière générale pour la partie échanges de données on est sur des formats fire dans le domaine de la santé, que ce soit pour le XML ou pour du JSON.
Isabelle MessinsD’accord. Nouvelle question pour Erwan. Pouvez-vous nous en dire plus sur les modèles de représentation des données pour réaliser de l'agrégation quand c’est autorisé ?
Charles Eric GiraultEn JSON, il n’y a pas de mécanisme d'agrégation intégré à notre solution. C'est aux partenaires et aux consommateurs de faire ce travail car il n'y a pas de mécanisme interne à l'application.
Effectivement, je parlais d'agrégats de mon côté et de données anonymisées. En fait, tout va dépendre de l'usage final de la donnée. Nous, on a des modèles en étoile, classique du BI. Chez nous, on peut aussi stocker dans le domaine de la santé au format ou OMOP.
Isabelle MessinsMerci, on peut passer à d’autres questions. Quelle est la taille du dispositif XXL ? Et est-ce que les utilisateurs ont un rôle de coopération ? Le travail avec eux est-il fluide et sont-ils proactifs dans le projet ?
Charles Eric GiraultAlors pour la partie agilité. Aujourd'hui, on a deux équipes agiles sur la solution XXL. On a d'autres projets liés mais pas directement dessus. Donc ça fait environ une vingtaine de personnes qui travaillent dessus.Ce n'est pas un développement extrêmement important en termes de lignes de code. C'est vraiment la capacité de rapidité qui est importante. Donc on n'a pas eu besoin de faire de l'agenda à l'échelle. C'était vraiment des petites équipes agiles qui travaillaient main dans la main. On parle d'agilité à l'échelle. Ensuite, on ne travaille pas directement avec les consommateurs. C'est le client qui va faire l'interface avec eux. Nous, on s'occupe de fournir la documentation nécessaire à l'utilisation de l'API. Cela passe par les contrats de service et les documentations techniques. Ensuite, on prend en compte les retours des utilisateurs transmis par les clients pour faire évoluer la solution en fonction de leurs besoins.
Isabelle MessinsÉtant donné le grand nombre de consommateurs, est ce que les échanges entre eux et les équipes de réalisation prennent une part importante de temps aux développeurs ?
Charles Eric GiraultOui, mais on n'est pas en lien direct avec eux. Donc non, c'est le client qui porte la majorité du temps d'échange avec les consommateurs.
Isabelle MessinsEt le rythme de la mise à disposition des versions de PLAT’AU est élevé. Comment l'ensemble des consommateurs de l'API arrivent à suivre le rythme ?
Charles Eric GiraultIl y arrivent plus ou moins. En utilisant PISTE, on leur donne toujours accès à plusieurs versions de l'API. Donc il y a une version d'API qui va être mise sur le long terme et d'autres versions d'API qui vont être mises à jour régulièrement. Donc on a deux environnements d'essai et d'expérimentation. Et donc, lles éditeurs qui ont besoin d'aller très très vite, vont se connecter à l'environnement qui est mis à jour régulièrement. Et les éditeurs qui ont besoin de plus de temps vont se connecter à l'expérimentation sur le plus long terme. Et même en production, on va se retrouver avec deux versions qui fonctionnent en parallèle de l'API, pour que les éditeurs aient plus de temps.
Isabelle MessinsD’accord, merci. Je vais reprendre une question d’Hélène qui va être pour vous 3. Elle faisait le lien entre les trois présentations. Elle a eu l'impression que ces différents projets pourraient permettre d'obtenir des données santé notamment, qui pourraient éventuellement déboucher sur de l'assurance. Et elle imagine que pour mettre en place tous ces projets, on aura besoin de monde dans le domaine du développement et de la data. Qu’en est-il ? J'ai une question aussi de Jérémie. Est ce qu'on peut imaginer ajouter une brique de traitement de données machine learning par exemple, dans l'ensemble de ces projets ?
Luc LangevinEn fait, on a une autre plateforme et je veux faire le lien avec. On intègre à la plateforme de HP des fonctionnalités data visualisation à des fins d'agrégation et de représentation de la donnée, pour une mise en valeur de la donnée avec différents outils. Big Data, Power bi, etc, à partir des données agrégées et anonymisées. Typiquement, on peut imaginer que des laboratoires souhaitent avoir des statistiques ou des informations pour leurs travaux. A ce moment-là, effectivement, on travaille avec des gens de la data sur l'aspect machine learning. Chez Sopra Steria, on a une autre plateforme qui s'appelle Inner Data. Elle est très orientée intelligence artificielle.Et effectivement, on est en train de créer des ponts avec Data et et HP, avec des algorithmes de machine learning.
Isabelle MessinsOK, merci. Une dernière question pour Charles, existe t-il une réflexion à propos du fait de transformer une erreur en offre catalogue pour des clients ?
Charles Eric GiraultC'est un sujet de réflexion séparé. On l'a déjà évoqué entre nous et émis l’hypothèse de faire une offre pré packagée qui serait installable un peu partout. Mais pour le moment, c’est un sujet qui est encore à ses débuts de réflexions. Nous n’avons pas encore tranché, cela reste une possibilité.
Isabelle MessinsUne autre question. Comment réagissez-vous pour vous démarquer des autres plateformes ? Et quelle place occupe l'IA dans ce projet ?
Luc LangevinPour l'IA j’ai parlé un petit peu du chatbot pour tout ce qui est support. Mais elle peut être utilisée pour autre chose, notamment pour tout ce qui est reconnaissance d'écriture. Par exemple, si on a des informations provenant d’un document scanné, alors on est capable d’analyser le contenu et de l'intégrer avec des informations exploitables derrière. Et pour se démarquer, car il y a d'autres plateformes c'est sûr on compte sur notre forte expertise et sur nos différentes applications. Donc je dirais que c'est ça principalement nos atouts par rapport à la concurrence.
Isabelle MessinsEt, est ce que les interfaces utilisateur font partie de la DHP ?
Luc LangevinNon. Si on veut un site web ou une application mobile, ça va être spécifique et c'est du développement spécifique à chaque fois.
Isabelle MessinsEt comment sont développés les micro services ?
Luc LangevinOn a pas mal d'outils qui nous permettent d'aller vite. Mais aussi des stacks classiques et open source basées sur du spring boot notamment et de la programmation réactive.
Isabelle MessinsEt quel est l'impact de l'incendie de Strasbourg pour la continuité de l'activité de la DHP ?
Charles Eric GiraultPour la partie API c’est effectivement du DevOps et du Java. On a besoin de tous les types de profils, qu'ils soient juniors ou expérimentés.
Replay Webinar - Cloud et Protection des données
Replay Webinar : Pourquoi et comment migrer son application .Net vers Kubernetes ?
Replay Webinar : Apache Kafka, the good, the bad and the ugly
Titre : Replay Webinar - Apache Kafka, the good, the bad and the ugly
Alioune Sy, directeur technique de la division télécoms, médias et jeux.
C'est bon, on est en direct ?
Jordan Desnoës, architecte de solutions.
C'est parti.
Alioune SyCa marche. Bonjour à tous et à toutes. Bienvenue à cette nouvelle édition des Tech Talk TME, désormais rebaptisée Let's Talk About I.T.. Aujourd'hui, on va vous parler d’Apache Kafka, de Kafka, The Good, The Bad, The Ugly. Pourquoi ce titre ? Déjà pour avoir un titre un peu catchy, cas qui attire l'œil. A priori, ça a bien marché parce que vous êtes quelques uns, vous êtes connectés ou en tout cas, vous êtes inscrits à ce talk. Mais au delà du titre, c'est parce que Apache Kafka est une solution qu'on apprécie assez fortement sur notre BU : télé, média et jeux pour tout un tas de raisons qu'on va vous expliciter dans les prochains Slides, mais également parce que ça répond assez, assez bien finalement aux enjeux actuels de nos clients qui sont de pouvoir traiter de l'information en temps réel sans forcément en différer. Voilà les traitements. Donc voilà l'idée de ce REX là, c'est de vous faire part en fait d'une part du fonctionnement d'Apache Kafka. Pourquoi c'est bien, pourquoi beaucoup de gens en parlent, mais également de vous passer un certain nombre de messages, de vous pointer un certain nombre d'éléments sur lequel il faut faire attention.Donc juste des éléments sur lequel on aurait aimé avoir été prévenus avant de se lancer dans cette grande aventure qui est Apache Kafka. Et donc, du coup, qui nous sommes à vos hôtes, bien moins pour commencer à Lyon. Je suis le directeur technique de la division télécoms, médias et jeux. Apache Kafka, je suis tombé là dedans il y a quelques années et je ne suis toujours pas ressorti de la marmite. Puisque comme je vous l'ai dit, c'est une solution qui marche bien, qu'on aime bien. Donc, au quotidien, j'accompagne nos équipes projets dans la mise en œuvre d'architecture, pas seulement sur Kafka, mais spécifiquement pour ceux qui feront de la page Kafka ils ont de la joie ou la malchance de me voir arriver sur leurs projets, notamment Jordan que j'en beth beaucoup en ce moment. Je te laisse la main Jordan ?
Jordan Desnoës, architecte de solutionsOui merci Alioune. Donc Jordan Desnoës, je suis architecte de solutions. Moi j'ai découvert et je me suis intéressé à Apache Kafka il y a maintenant trois ans de cela. C'était dans le cadre d'une rénovation technique, d'un projet critique pour un opérateur télécom. Projet critique puisqu'il devait allier à la fois performances mais en même temps garantie de séquentialité des traitements, donc garantie de l'ordre. Donc c'est là que j'ai mis en place Apache Kafka sur ce projet qui est maintenant en production et qui fonctionne plutôt bien. J'interviens également de façon ponctuelle, donc sur des projets qui, un peu comme Alioune qui souhaite mettre en place Apache Kafka. Donc en tant qu'auditeur, l'idée étant de voir si, si, la configuration et la façon dont il met en place Apache Kafka correspond aux besoins du projet. Et s'ils n'ont pas omis certains éléments qui pourraient leur porter préjudice en production pour la suite notamment.
Alioune SyTout à fait merci Jordan. Et donc du coup, comme vous l'avez deviné, la présentation va se structurer en trois parties. Pendant que The Good, The Bad et The Ugly et en termes de règles du jeu, n'hésitez surtout pas à nous transmettre vos questions au travers du chat. On va se réserver un temps à la fin de la présentation pour pouvoir y répondre et échanger autour de ces de ces questions que vous pouvez avoir. Apache Kafka- The Good. Pourquoi Apache Kafka c’est bien et comment ça marche ? Mais tout simplement qu'est ce que c'est Apache Kafka ? Apache, Kafka est une plateforme de streaming qui est plutôt adaptée à la mise en œuvre en fait d'architecture événementielle. Pourquoi on évoque le fait que ce soit une plateforme de streaming ? Parce que c'est en première intention, Message broker qui permet de faire transiter des événements au sein du SI. Mais tout autour de ce broker de messages, il y a un certain nombre d'outils ou d'API de haut niveau qui permettent progressivement de mettre en place des cas d'utilisation un peu plus compliqué que juste faire transiter des événements au sein du SI.Donc c'est vraiment ça qui est intéressant avec Apache Kafka, c'est que la prise en main et la mise en œuvre peut être faite de façon itérative au fur et à mesure que vous montez en compétences et en maturité sur la technologie. Typiquement, vous pouvez commencer par des Use Case assez simples, en fait en utilisant Kafka comme message broker tout simplement. Donc pour émettre des événements, les recevoir au niveau de deux des applications, puis faire des traitements subséquents suite à la réception de ces événements. Donc ça, c'est vraiment l'usage basique. Tout comme vous pouvez utiliser un RabbitMQ ou ce genre de choses là. Et après ça vous pouvez progresser vers d'autres Use Case un peu plus compliqué. Et typiquement vous pouvez faire ce qu'on appelle du CDC de Change Data Capture pour pouvoir capturer l'ensemble des mises à jour qui sont réalisées au niveau du data store un peu plus classique, une base de données. Publier des événements suite à ces mises à jours là et réagir en temps réel à des modifications. Donc ça, ça permet d'adresser des Use Case de transition, par exemple de traitements de type batch vers des traitements événementiels.Là où on aurait accumulé un certain nombre de données dans une base de donnée, on les et on les aurait traitées à J+20 en faisant du CDC, en déversant des événements en temps réel dans Kafka. Vous pouvez commencer à faire une transition un peu transparente, on va dire. On a une transition simplifiée vers des architectures un peu plus de temps réel. Et si vous avez un peu plus loin, vous pouvez utiliser Apache Kafka pour des traitements vraiment purement événementiels, pour faire de la détection de fraude, etc et cetera voire brancher des outils un peu plus évolués tels que du Spark, du Hadoop. Voilà donc, c'est vraiment ça la richesse de Kafka. C'est qu'en première intention c'est juste un broker de messages et au fur et à mesure que vous gagnez en maturité, bah vous pouvez l'utiliser finalement pour des Use Case un peu plus évolués. Comment ça fonctionne Apache Kafka ? Comme je l'ai dit, c'est un broker de messages qui permet de faire transiter des événements au sein du SI, éventuellement même entre deux applications.Première chose à savoir, c'est que chaque Apache Kafka est nativement distribuée, donc c'est une. C'est une solution qui se base sur une architecture qui est en mode cluster nativement. Contrairement à d'autres solutions où il faut activer des plugin, il faut soit prendre des licences payantes ou faire une configuration spécifique de base. Apache Kafka fonctionne de façon distribuée en cluster. Donc il suffit juste de démarrer plusieurs instances d’Apache Kafka en les faisant se découvrir les unes les autres et automatiquement, elles vont former un cluster. Première notion. Ensuite, l'élément de base qu'on va manipuler dans Apache Kafka, en fait, ce sont des topics. Donc on publie des événements au sein de topics qui vont avoir une connotation ou ont un sens fonctionnel cohérent. Donc vous pouvez avoir par exemple un topic pour gérer les l'ensemble des événements qui sont liés à une facture, un topic pour l'ensemble des événements qui sont liés en contrat etc etc. Donc de base on va manipuler des topics qui sont des autoroutes de transfert des évènements si je puis utiliser cette image là.Et les topics sont eux mêmes subdivisés en partitions logiques et ses partitions sont elles mêmes répliquées au sein du cluster, en fait, pour assurer de la haute haute disponibilité et de la résilience au niveau d’Apache Kafka, qu'est ce qui fait que par exemple, là dans c'est dans l'illustration qu'on est là, si la partition zéro, si le broker un zéro un tombe bien, la partition zéro est toujours disponible parce qu'elle a été répliquée dans le broker un zéro deux. Donc ça c'est également une des forces de Kafka. La possibilité de répliquer automatiquement les données au sein des partitions. Ensuite, ce qui est également intéressant de noter, c'est que aussi une partition va être gérée au niveau de Kafka comme un Commit log qui persiste la donnée. Donc on publie un événement dans Kafka, il est sauvegardé sur le disque. Donc contrairement à d'autres brokers qui ne fonctionnent qu'en mémoire où, on arrête le broker, on perd l'ensemble des informations, Kafka persiste la donnée. Et ce qui est intéressant c'est que les données sont persistés en fait en fonction de leur ordre d'arrivée.Donc vous pouvez voir en fait les partitions dans Kafka, un peu comme une grosse liste où à chaque fois on va positionner le dernier élément à la fin de la liste. Et ce qui est vraiment intéressant, c'est que chaque producer produit la donnée à son rythme. Donc il ajoute des éléments à la liste, aux logs ou encore à la partition. Et les consommateurs peuvent consommer les événements à leur rythme également. Donc, vu que les événements sont persistés et que quand un consommateur lit la donnée, il reste toujours disponible pour les autres. On peut avoir plusieurs consommateurs qui lisent la donnée à des rythmes un peu différents. Typiquement, on a le système A qui est sur l'événement quatre, le système B qui est sur l'événement dix, et cetera, et cetera. Et Kafka conserve en fait l'offset de lecture, donc l'index de lecture de chaque consommateur, pour qu’à chaque fois qu'un consommateur demande à lire des événements, on lui donne l'événement suivant par rapport à l’index sur lequel il est positionné. Qui fait qu'on peut avoir plusieurs consommateurs qui consomment la même donnée sans pour autant avoir de la perte de données.Donc un événement dans Kafka est vraiment identifié à partir de l'offset, sa position dans la partition. Ce que je n'ai pas précisé du fait de la réplication puis des propriétés de haute disponibilité de résilience, on ne peut pas avoir un broker qui à plusieurs répliqua de la même partition en fait. Typiquement, si on définit que la partition zéro doit avoir trois replica, les réplicats doivent être sur des brokers différents. Sinon ça ne sert pas à grand chose au final. Et donc comment les événements sont ventilés dans les partitions ? Ça va dépendre de plusieurs facteurs. À un événement donné qu'on publie dans Kafka, on peut lui associer une clé et la clé va finalement être un vecteur ou un moyen de distribution des événements au sein de la partition. De base, quand vous configurez pas spécifiquement Kafka, ce que Kafka va faire pour déterminer la partition d'arrivée d'un événement, c'est un H de la clé modulo le nombre de partitions. Ce qui fait que tous les événements qui ont la même clé vont se retrouver dans la même partition.Et ça, c'est vraiment une des bonnes pratiques à observer quand vous utilisez du Kafka. En tout cas, quand vous publiez des événements sur Kafka, c'est de pouvoir associer chaque événement à une clé fonctionnelle, de telle sorte à ce que les événements qui sont reliés à la même clé se retrouvent dans la même partition. Et ça, c'est un élément primordial. Pourquoi ? Parce que Kafka ne garantit pas l'ordre de traitement au global au sein d'un topic. Si vous avez un topic qui a trois partitions, Kafka ne garantit pas en fait que quand vous allez consommer la donnée, vous avez, vous allez consommer tous les événements de la partition zéro. Ensuite, les événements de la partition un et après les événements de la partition deux. Kafka, garanti juste que, au sein d'une même partition, vous allez recevoir les événements dans l'ordre de production. Donc typiquement là vous pouvez recevoir un deux…. les ronds, les étoiles, les carrés, mais tout en préservant l'ordre au sein de chacune des partitions. Et donc, du coup, si vous avez besoin d'avoir un mode de traitement spécifique, par exemple, vous envoyez des lignes de factures dans Kafka.Vous devez vous assurer d'associer chaque ligne de facture à la même, au même identifiant de facture, de telle sorte que toutes ces lignes de factures se retrouvent dans la même partition. Donc vous les traitez dans le bon ordre en fait. Donc ça c'est vachement important, la clé de de partition qui est associée à chaque événement. Et à côté de ça ? Ce qui est intéressant dans Kafka, c'est la notion de Consumer Group. Un Consumer group en fait à permet de regrouper des consommateurs d'événements au sein d'un groupe logique, de telle sorte que la lecture Kafka distribue en fait les partitions à chaque membre du Consumer Group. Et le Consumer Group, on va généralement utiliser pour identifier en fait les instances d'une application. Typiquement, j'ai une application qui doit traiter des factures. J'ai démarré trois instances de mon application. Donc je vais les mettre dans le même Consumers Group, de telle sorte à ce que chacune des instances traitent une et une seule partition et qu'il n'y ait pas une partition qui soit traitée par plusieurs instances.
Alioune SyDonc c'est comme ça que Kafka garantit l'ordre de traitement, même en cas de multiple consommateur sur un topic. Je passe la main à Jordan.
Jordan DesnoësOui, merci Alioune. Donc une des forces de la page Kafka, c'est aussi son écosystème. En effet, Apache Kafka propose un écosystème qui est très très riche. Donc au-delà des simples consumer producer dont on a parlé Alioune juste avant, qui existe dans diverses langages tels que le C++, Java, DotNet et Python, on retrouve trois API de haut niveau. Donc chacune va être dédiée à un usage un peu spécifique et qui va vous faciliter la vie en fonction des traitements que vous avez à accomplir sur les événements issus ou à destination de Kafka. Donc si je prends la première API de haut niveau, c'est Kafka Stream. Donc quand on décrit sur la gauche donc une API qui permet de faire du streaming pseudo temps réel autour d'événements dans Kafka. Donc l'idée c'est de consommer des événements issus de Kafka et de les publier à nouveau dans un autre topic de Kafka. Donc vraiment du traitement de Kafka vers Kafka, Donc cette API, elle est très intéressante pour ce besoin là puisqu'en fait, elle va faire abstraction de toute la partie technique, de toute la couche technique qui permet de faire le poling et la production de données vers Kafka.Donc tout ça, c'est géré de façon native via cette API. Donc vous allez pouvoir vous focaliser sur le code métier de votre application. Et pour ça une API, une un langage de type DSL, un domaine spécifique langage est également proposé. Il va faciliter toutes les opérations de type jointures, groupement, filtrage, mapping, et cetera. Enfin, l'API Kafka Stream propose deux types de sémantique. Donc la première type de sémantique, c'est la ALO. Cette sémantique garantit, via Kafka Stream, que tous les événements consommés depuis un topic Kafka seront traités à minima une fois. Et pour aller un peu plus loin et éviter les doublons de traitement, une seconde sémantique est proposée - la sémantique EOS. Donc avec cette sémantique qui s'active simplement via de la configuration. Donc vous n'avez pas à gérer toute la partie technique de transactionnalité, de le rollback et cetera. Vient simplement de la configuration. Vous allez pouvoir assurer qu'un événement consommé via Kafka Stream sera traité exactement une fois. Donc on a un petit exemple de code sur la gauche qui indique au fait qui permet en trois lignes de compter les mots issus de messages provenant d'un topic Kafka et pour ce qu'à chaque comptage fait de produire le résultat dans un autre topic Kafka qui sera appelé topic 2.Second API de haut niveau - l'API KsqlDB. Donc là c'est une API qui intervient en tant que couche au-dessus de Kafka Steam. Est fourni un langage de type SQL. Donc vous avez simplement à écrire des requêtes SQL et ces requêtes vont être transformées ensuite en en code Kafka Stream. Finalement, vous n'avez plus de code à faire si ce n'est de la rédaction, l'écriture de requêtes SQL. Ce qu'il faut voir ensuite, c'est que la requête en question va être exécutée à l'infini en continu. Cette requête n'aura pas de fin et donc l'idée c'est de pouvoir, de même façon que via du Kafka Stream, produire des résultats dans un topic Kafka en continu. Les Use Case typiques pour ce pour l'usage de KsqlDB, ça va être par exemple du monitoring temps réel ou bien également de la gestion de fraude par exemple avec de l'alerting en continu. Donc si on passe maintenant sur la troisième API de haut niveau, elle s'appelle Kafka Connect. Elle permet l'intégration, que ce soit en entrée ou en sortie, de Kafka, avec d'autres systèmes que des systèmes externes et hétérogènes. Par un système externe hétérogène.J'entends notamment des bases de données, des broker de messages ou autres tels que RabbitMQ, MQSeries ou autre, également de Elastic Search, ou même des services web tels qu'Amazon S3 par exemple. Le but de Kafka Connect est de proposer cette interface entre Kafka et l'autre système de façon très simple et rapide. L'idée, c'est que sur le marché ou sur le marché web, vous allez retrouver plein de connecteurs prêts à l'usage, prêts à l'emploi et vous pour les mettre en œuvre. Vous n'avez qu'à faire de la configuration au format Json, comme le montre l'exemple à droite. Donc pas de développement nécessaire pour interfacer Kafka avec un autre système. Ça permet d'aller très rapidement et se focaliser sur le code métier. Enfin, est-ce que Kafka Connect propose toute la partie résilience et haute disponibilité de façon native, puisque Connect peut fonctionner en mode distribué ? Et donc ça permet de s'abstraire de cette couche technique. Et dernière chose, la Kafka est configurable via une API REST.Et donc il suffit de faire des appels REST de type curl par exemple pour pouvoir configurer à souhait et à chaud vos connecteurs Kafka. L'écosystème Kafka ne s'arrête pas là. On retrouve principalement trois distributions de la plate-forme Apache Kafka. La première qui est la licence Apache 2.0 qui est totalement open source et qui va proposer les fonctionnalités cœur d'Apache Kafka. Par les fonctionnalités cœur, on entend le broker, l'API Consumers, l’API producteur et également la partie Kafka Connect et Kafka Stream décrit précédemment. Au-dessus de cette couche gratuite et opensource, on retrouve la licence communautaire et la distribution communautaire de l'éditeur Confluent. Elle va apporter des fonctionnalités supplémentaires, notamment. Qu'est ce que le LDB ? Chemin enregistré ? Qui vont vous aider tout au long du développement. On retrouve un certain nombre de connecteurs Kafka Connect prêts à l'usage, distribués par Confluent également. Cette distribution est également gratuite et vous pouvez en plus de ça bénéficier du support Confluent au besoin. Dernier type de distribution qui est la distribution commerciale de Confluent.
Donc là, ça va être principalement l'apport d'outils qui vont vous être proposés. Donc des outils, notamment de monitoring par exemple la console, le Control Center qui vous permet d'avoir un état des lieux en état de vie de votre cluster Kafka, et d'autres outils pour assurer la résilience et la sécurité de votre cluster Kafka. Résilience et Sécurité, notamment la réplication de votre cluster vers un autre data center. Chose qui n' est pas possible de base avec les distributions gratuites. Et du coup, qui dit licence commerciale dit aussi support de la part de l'éditeur. Donc trois niveaux de support: le support Silver, le support support Gold et le support Platinium. A noter cependant sur la partie connecteurs qui sont disponibles en licence communautaire que certains sont proposés sous forme d'évaluation. Au bout de 30 jours, vous allez devoir souscrire à la version commerciale pour pouvoir continuer à les utiliser. Maintenant on va passer sur la partie Bad de Kafka. Ce qu’on entend par la partie Bad de Kafka ? C'est tout ce qui va être des choses que vous n'aviez pas prévu parce que vous ne vous étiez pas assez documentée sur le produit.Vous, vous n'aviez pas connaissance du fonctionnement interne du produit et donc c'est des choses qui peuvent vous surprendre en production lorsque vous allez les rencontrer. Donc pour commencer, on va s'intéresser un peu plus au producer, donc le producteur de l'événement dans Kafka. Donc va voir comment il fonctionne avant de voir ce qui se cache derrière en termes de pièges. Donc, il faut savoir que le producteur Apache Kafka y veut. Il a pour but d'offrir une logique événementielle et en même temps de permettre du micro batching. On va voir cela, donc il fonctionne de façon asynchrone, nativement et par défaut. L'idée étant de ne pas aller contre ce type de fonctionnement. Pourquoi ? Principalement parce que ce fonctionnement asynchrone va vous offrir des performances meilleures que synchrone. Typiquement, tout un tas de choses va être faite en asynchrone. La première étape de la sérialisation des données. L'idée étant de pouvoir transformer les données d'entrée en sous forme de tableaux de bites afin de pouvoir les faire ingérer au broker Kafka puisqu’il ne gère que les tableaux bites.Deuxième étape faite de façon asynchrone, c'est le partitionnement. Donc décrit par Alioune juste avant afin de choisir la partition concernée par notre événement. Et enfin, et non des moindres, la dernière étape l'étape de batching qui consiste à accumuler pour une partition et un topic donné les événements qui sont dédiés à ce même topic et partitions. Derrière ça se cache vraiment un aspect d'optimisation de performances puisqu'on souhaite, pour limiter les requêtes réseau entre le producer de données et le broker Kafka. Qui dit limitée dit batching, donc accumulation de données pour les envoyer sous forme de lots au broker Kafka et donc limiter les requêtes et gagner en rapidité et en temps. Enfin, il faut savoir que le producer, de façon native, donc sans même avoir à implémenter cette partie là, devient du code ou de la technique. Il va proposer tout ce qui est une gestion de retry de façon automatique. Cette gestion d'héritage est configurable soit via un certain nombre de retry que vous avez paramétrer, soit via un délai à ne pas dépasser.Donc elle va permettre principalement cette gestion des retry automatiques de couvrir des cas d'erreurs, notamment liés à des glitch réseau, par exemple la perte de communication entre le broker et le producteur. Donc ce retry va pouvoir de façon transparente, pallier ces problèmes là. Si le nombre de retry est configuré ou le délai configuré expire, une exception va être remontée au producteur qui a, au choix, pouvoir la gérer ou la renvoyer ou l'ignorer. Voilà concernant l'anatomie du producer. Donc maintenant qu'on a vu un peu comment il fonctionnait, on va voir quel piège peut se cacher derrière ce fonctionnement. Donc pour ça, on va se focaliser un peu sur le fonctionnement des replica. Donc comment les données sont répliquées d'un broker à un autre. Donc pour chaque partition, on a ce qu'on appelle un leader et un follower. L'idée étant que le leader va être le premier à persister la donnée et que les followers vont ensuite pouvoir aller chercher la donnée auprès de ce leader. Donc ils vont venir se synchroniser par rapport à ce leader au fur et à mesure.Dans notre exemple, on a trois brokers. On a défini un facteur de réplication de trois, ce qui indique qu’on souhaite que notre donnée soit persisté à trois entre trois endroits différents. Donc le broker 101, le broker 102 et le broker 103. Le producer va écrire la donnée dans le broker 101 et les brokers 101, 102 et 103 vont venir se synchroniser pour récupérer cette nouvelle donnée. Donc on a vu ce mode de fonctionnement des répliques. On va s'intéresser aux garanties qu'il offre qu'offre le produit producer, qui sont notamment au niveau des équipements. Il en existe trois niveaux, trois types d'aliments différents. Donc le premier mode d'acquittement qu'on a appelé YOLO. Vous allez vite comprendre pourquoi. L'idée étant qu'au fait, le producteur ne vérifie pas. Il ne s'attend pas à avoir un acquittement de la part du broker. Donc c'est vraiment un mode Fire and Forget. Le producer envoie la donnée. On n'a pas de garantie que la donnée a été persisté côté broker, mais on continue nos traitements.Donc du coup, c'est le mode le plus performant puisqu'on passe à la suite des traitements sans manches sans même attendre. Mais par contre, c'est aussi le mode le plus risqué puisqu'on n'a pas de garantie que la donnée était persistée. Donc le cas d'usage, ça va être par exemple des événements qui vont être auto porteurs et qui vont et pour lesquels, du coup, la perte d'un événement intermédiaire ne va pas influer sur le résultat final des traitements. Le deuxième mode qui offre un compromis entre performance et résilience, c'est le mode Leader Ack. Donc, dans ce mode, le producer va attendre l'acquittement seulement du broker leader de la partition. Dès que le leader de la partition a fourni l'acquittement, il a indiqué avoir persisté la donnée, le producer va pouvoir passer à la suite. Donc ça, ça offre un bon compromis. Mais il faut savoir que ce n'est pas un mode exempté de défaut. Il faut bien avoir en tête que l'on peut toujours avoir des pertes de données avec ce mode.Je m'explique. Dans notre cas, notre producer va envoyer la donnée au broker 101, le broker 101 va la persister et à la suite, le producer va pouvoir passer à la suite puisqu'on a reçu l'acquittement. Cependant, en cas de crash du broker 101, donc du broker leader avant que les synchros, que les que les followers, donc que les deux autres brokers soient venus se synchroniser et récupérer la donnée pour la persister chez eux. Si le broker 101 crash entre temps, la donnée n'étant présente qu'à cet endroit, elle sera définitivement perdue jusqu'au redémarrage de ce broker. C'est un mode qu'il faut bien avoir en tête. Il peut entraîner des d'événements également. Donc ceci étant dit, on va pouvoir passer au mode le plus sûr, le plus résilient qui est le mode In Sync Replicas Ack ! Donc, contrairement au modèle Leader Ack, on va attendre dans ce mode d'acquittement que la donnée soit répliquée à la fois sur le broker leader mais également sur les brokers followers. Donc pour ça. Le broker 101 donc le broker leader qui est le seul avec qui on communique……Va nous renvoyer l'acquittement, seulement une fois qu'il est certain que les brokers followers auront récupéré la donnée également. Attention cependant, intervient à ce moment une notion qui indique le nombre minimum de replicas qui doivent synchroniser la donnée. Donc on a indiqué que nous, on voulait un facteur de réplication de trois. Mais s'ajoute à ça la configuration du nombre minimum, dit SR qui par défaut est à un. Ce qui indique que si mes deux autres brokers - followers sont K.O, mon nombre minimum d’ISR étant un 1, je vais quand même avoir un acquittement puisque je remplis ce contrat. Donc si on veut rendre ce mode au plus résistant possible, il faut configurer un nombre minimum de replicas synchronisés supérieur à un. Donc dans notre cas compris entre deux et trois. Donc ce mot étant donné que c'est le plus sûr, il intervient surtout dans des Use Case où on ne veut pas perdre de données ou par exemple des transactions bancaires ou des données métiers très importantes. Il est indispensable de bien avoir ça en tête et du coup, de paramétrer son équipement en fonction de nos besoins, à la fois sur la partie producer, mais également sur les brokers et topics qui sont également porteurs de configuration. Je pense notamment au nombre de replicas minimum. Le min ISR qui va pouvoir se configurer au niveau broker et topics et pas au niveau producer. Ça donc bien avoir une notion de ces trois niveaux de configuration pour obtenir les garanties souhaitées.
Alioune SyDonc merci Jordan. Effectivement, il y a pas mal de pièges dans lesquels on peut tomber si on ne configure pas correctement ou si on ne prend pas garde à la configuration du producer de données. Et il en est de même pour la partie consommateur de données. Ce qu'il faut également garder en tête, c'est que les Consumer API Consumer de Kafka fonctionnent un peu comme l’API producer, dans le sens où ça va fonctionner par batch. Donc quand vous consommez des événements dans Kafka, vous ne les consommez pas un à un. En fait, vous récupérez un batch d'événements, que vous traitez. Vous commitez l'offset de dernier événement que vous avez traité, et ainsi de suite. Donc, si on regarde comment ça fonctionne finalement avec une sorte de timeline à trois temps. En T0, imaginons que le dernier offset qui avait été commité c’est Offset 2. Donc dans le code qu'on va faire en consumer pool pour récupérer un certain nombre d'événements à traiter. Kafka va à vous, va nous envoyer un batch, donc là, en occurrence, il nous envoie les événements 2, 3, 4 et 5.OK, donc tout va bien. On a récupéré quatre événements, on va faire une boucle pour les traiter. Ce que vous ne savez pas ? En tout cas, on ne sait pas forcément quand on démarre sur du Kafka. C'est que dans l'API consumer par défaut quand on démarre un consommateur d'événement, Kafka démarre en Thread, également en tâche de fond pour faire de l'auto commit des offset. Donc en gros ce Thread là qu'est ce qu'il va faire ? Et il va regarder le dernier batch d'événements qu'on a reçus. Il prend le dernier événement et toutes les cinq secondes il va commiter automatiquement dans Kafka en disant - positionne les offset de mon consumer à 6. Parce qu'il a déjà récupéré deux, trois, quatre et cinq. Ça peut être assez intéressant parce que finalement, ça nous décharge de tout ce travail de gestion un peu fine des Offset. Sauf que ça, c'est dangereux parce que qu'est ce qu'il peut se passer ? Donc en T0, on a récupéré les événements deux, trois, quatre cinq en t0 + cinq secondes……Donc on a un casque en tâche de fond qui va commiter l'offset. OK, ça c'est transparent pour moi. Sauf que nous, on en est toujours par exemple dans notre boucle de traitement des événements. Donc on a traité l'événement deux et trois, donc on va continuer. On va essayer de traiter quatre et cinq. Donc en t0 + sept secondes, donc le dernier, on avait traité deux, trois, on est en train de traiter quatre et boum - une erreur. Qu'est ce qu'on va faire sortir de notre boucle ? Éventuellement ce qu'on fait, un try catch, et donc on va revenir au niveau du consumer policy pour demander à Kafka de nous renvoyer les événements. Car on pourrait s'attendre, si on ne comprend pas bien le fonctionnement de Kafka, à ce qu'il nous renvoie le même batch d'événements, vu qu'on n'a pas commité l’offset, mais vu qu'il a été commité automatiquement par Kafka juste avant, à t0 plus cinq, est ce que ça va faire ? En fait, c'est que quand on va refaire un consumer poll, ici dans le code, Kafka va nous renvoyer un batch d'événements à partir de l’offset 6 qui a été comité automatiquement par le consumer.Ce qui va faire finalement qu'on va se retrouver dans une situation où on a perdu des événements parce que les événements deux et trois, on les a traités. Quatre - on était en train de le traiter, mais on en a craché. Cinq - on n'en parle même pas et au prochain Consumer Poll, on reçoit six, sept, huit et neuf. Moralité - on aura perdu deux évènements qu'on n'aurait pas traités et de façon totalement arbitraire et transparente. Donc il faut vraiment faire très attention lorsque vous consommez des événements avec Apache Kafka parce qu'il a ce comportement d'auto commit toutes les cinq secondes. Donc il faut toujours penser à désactiver l'auto commit des offset au niveau de l'API Consumer pour pouvoir gérer vous même les offset, une fois que vous êtes sûr que vous allez traiter tout le batch que vous avez récupéré de Kafka. Ou alors si vous laissez cette configuration là, faut vraiment savoir pourquoi vous le faites et s'il est vraiment adapté à votre Use Case. Est ce qu'il faut également garder en tête que la plupart des librairies, un peu au niveau que vous allez trouver sur GitHub, sur je ne sais pas quel dépôt public fonctionnent également de cette manière de la même manière.En fait, il ne désactive pas l'auto commit par défaut. Donc faites vraiment attention à cette configuration qui peut vous entraîner dans des situations un peu bizarre. Et de façon un peu similaire aussi, si vous ne comprenez pas bien comment fonctionnent les transactions dans Kafka, vous pouvez vous retrouver dans des situations un peu bizarroïdes. Parce que depuis les dernières versions de Kafka, elle gère la notion de transaction. Sauf que les transactions dans Kafka, ça ne fonctionne pas comme des transactions en base de données. En fait, c'est pas des transactions acides au sens relationnel du terme. Donc typiquement là je vous ai matérialisé en fait une partition dans Kafka où on lit un certain nombre d'événements. Donc comment ça se lit ? On va considérer que les événements qui sont noirs, ce sont des événements qui ne font pas partie d'une transaction. Les événements qui sont bleus, ce sont des événements qui font partie d'une transaction et les événements en rouge, on va le voir en détail. Globalement, dans Kafka, quand vous voulez activer les transactions, c'est au niveau de l’API.Ben vous faites Int transaction, Begin transaction. Un peu comme ce que vous auriez fait dans une base de données. Et ensuite là par exemple on fait une boucle ou on va envoyer cinq événements qui correspondent à un, deux, trois, quatre et cinq, ici en bleu. Et donc dans le cas d'usage, là juste à la fin de la boucle, en faire un abord de transaction. Donc typiquement naïvement, quand on voit ce code là, on pourrait se dire finalement, on a fait cinq fois, on a fait un abord de la transaction. Donc il n'y a aucun événement dans Kafka. Sauf que dans la vraie vie, quand vous activez les transactions dans Kafka, qu'est ce que ça fait ? Rappelez vous ce que j'ai dit. Les événements qu'on envoie dans Kafka sont persistés sur le disque. Donc, une fois qu'on est un événement, il est écrit, il est écrit, on ne peut pas le supprimer, on ne réécrit pas le passé. Ce que fait Kafka et que quand vous activez les transactions, c'est que finalement, il va envoyer des événements un peu spéciaux dans les partitions qui sont des événements qui vont délimiter des frontières transactionnelles.Typiquement, quand on a fait un Begin transactions ici, Kafka a rajouté un événement de début de transaction. Ensuite, chacun des événements qui ont été publiés dans la boucle sont vraiment émis dans Kafka, mais avec une métadonnées qui les rattache à une transaction pour dire qu'ils sont rattachés à ce marqueur transactionnel qui est là. Ça suit son cours et avec le Abort Transactions finalement, Kafka a publié un événement également qui délimite la fin de la première transaction, mais en précisant que la transaction a été abordée. Donc, ce qui va se passer si vous utilisez un consumer qui n'est pas configuré de façon spécifique, si vous utilisez juste la configuration de base, quand vous allez faire consumer poll, et cetera, et cetera, vous allez vous retrouver à lire tout ça en fait. Donc y compris les événements non transactionnels X, Y, Z et les événements qui faisaient partie de la transaction, même s' ils avaient été abordés. Donc vous allez lire un, deux, trois, quatre, cinq à tort et donc pour éviter ce genre de problématique….En fait, il faut configurer explicitement le consommateur pour lui dire qui doit être en read committed qui ne doit lire que les événements non transactionnels, typiquement les événements en noir dans ce schéma là ou les événements qui font partie d'une transaction mais pour lequel on a un événement marqueur de fin de la transaction qui est non pas Abort mais Commit. Donc en l'occurrence, si on configure le contenu mais en read committed, on va dire x, y et z uniquement. Donc moralité - les transactions c'est bien mais ça ne fonctionne pas comme les transactions en base de données. Faut vraiment faire gaffe à ça. Et dès lors que vous utilisez quelque part dans votre récit des transactions, il faut que tous les consommateurs d'événements en aval de cette application là. Donc, ils vont lire des événements qui sont produits par l'application qui a activé les transactions. Il faut qu'ils soient en read committed. Sinon, vous vous exposez au risque de lire des événements qui ont été rollback. Et du coup je te repasse la main Jordan.
Jordan DesnoësTout à fait. Donc maintenant nous allons entamer la partie The Ugly d'Apache Kafka. Donc qu'est ce qu'on entend par la partie The Ugly ? Finalement, ça va être toutes les notions que vous avez vu dans la documentation que vous avez mis en œuvre, avec peut être des choses qui vous ont échappé et qui amènent à de drôles de comportements en production par exemple. Alors pour illustrer ça, un premier exemple, donc il faut savoir que les crashs ça n'arrive pas qu'aux autres. Alioune et moi même avons rencontré plusieurs crashs de nos applications, de nos clusters Kafka. Et donc ceci est un exemple dont nous allons vous parler. Donc dans mon cas, j'ai deux data center : data center 1, data center 2. Chacun de ces data centers contient deux brokers Kafka avec un seul topic constitué de quatre partitions. Donc j'ai vu qu' avoir des replicats c’est bien. Je suis là, je suis un peu le Tech Talk. Et au niveau des processeurs, je peux configurer un facteur de réplication et un facteur minimum de replica.Donc j'ai positionné ces de ces deux configurations à la valeur deux, ce qui me garantit que ma donnée sera persistée deux fois au minimum. Donc ça pour moi tout est ok. Là intervient mon premier crash de data center, donc je perds mon data center numéro un, ce qui implique la perte de mon broker numéro un et de mon broker numéro deux. Donc jusque là je suis plutôt confiant parce que j'ai bien suivi la doc, j'ai mis, j'ai configuré tout comme il fallait, je sais que j'ai des répliques dans tout, donc tout devrait fonctionner. Sauf que, en regardant un peu dans le détail bien fait, il n'y a plus rien qui fonctionne. Alors pourquoi ? Donc si je prends l'exemple de mon topic 1 partition numéro 1, là je me rends compte que finalement cette partition numéro 1 était présente dans le broker 1 et également dans le broker 2. Donc deux répliquas comme je l'avais indiqué, mais manque de pot, ces deux brokers se trouvent dans le même data center. Donc finalement boum, j’ai pu les données associées donc je ne peux plus continuer à produire sur cette partition.Bon, passons donc on va s'intéresser maintenant dans la partition zéro du topic 1. Donc là j'ai un peu plus de chance. Elle était répliquée à la fois sur le broker 1 et également sur broker 3. Donc j'ai encore le bon broker 3 dans data center 2 donc finalement super. Je vais pouvoir continuer à me servir de cette partition à minima et sauf que boum encore. Pourquoi ? Tout simplement parce qu'en fait j'ai défini un facteur de réplication à deux et un nombre de répliques minimum à deux. Sauf que là, je viens de perdre un replica, donc je ne satisfait plus mon nombre de répliques à minimum, puisque je n'ai qu'un seul répliqua en data center 2. Mon producer, par conséquent ne peut plus écrire de données dans cette partition. Donc finalement c'est comme si la partition est également hors service. Donc j'ai pourtant j'avais tout bien fait. J'avais configuré des replica. Donc ce qu'on a dit que c'est qu'avoir des répliques c'est bien savoir où ils sont, c'est encore mieux. Donc pour éviter dans le premier cas d'usages qu'on l'on de voir, pour éviter d'avoir une partition répliquée dans deux brokers qui se trouvent dans le même datacenter…La notion de rack awareness a été inventée et elle a été positionnée dans la plateforme Apache Kafka. Donc finalement, le rack awareness est une notion qui va permettre de disperser la donnée dans différents brokers qui se trouvent, eux, dans des rack, dans des data centers, dans des salles machines différentes, ce que vous voulez. Mais l'idée étant de disperser la donnée selon une configuration que vous allez mettre en place. Donc en l'occurrence, j'aurais pu définir un rack pour mon data center 1, un rack pour mon data center 2. Ce qui garantit que Kafka va disperser la donnée dans ces deux data centers et éviter d'avoir tout dans le même. Donc ça, ça répond à la première problématique que j'ai rencontrée. Et pour la seconde problématique rencontrée de non satisfaction du nombre minimum de réplicants. Le mieux finalement, c'est encore d'avoir un facteur de réplication qui va être supérieur au nombre de répliques minimum que je veux avoir à tout moment. Donc c'est pour ça que la configuration facteur de réplication doit être supérieur au facteur minimum de réplique.Tout ça pour dire qu'avoir un plan de reprise d'activité et d'avoir ça en tête, c'est pas mal. Comme je l'avais là. Sauf que le mieux, c'est encore de tester en conditions réelles avant de rencontrer des problèmes en production. Et ça nous permet finalement d’éviter ce genre de maladresses et de choses qui peuvent arriver si on n'était pas bien informé du fonctionnement. Donc Kafka, c'est quand même une plateforme qui propose des performances assez intéressantes. Je vous en parlait tout au début en introduction. C'est comme ça que j'ai mis en place, que je me suis intéressé à cette plateforme. Sauf que c’est pas exempté de tout problème de performance, que ce soit au niveau de la plateforme elle-même ou au niveau de l'écosystème de son environnement d'exécution. On peut rencontrer des problèmes de perf comme sur tout système en fait. Et donc, si on rencontre des problèmes de perfs, l'idéal c'est de pouvoir dire où est ce qu'ils sont quoi. Donc sur une chaîne qui va du producer en passant par les broker Kafka pour aller jusqu'au consumer ?Ça fait quand même pas mal d'événements, d'éléments à analyser pour trouver la raison de nos problèmes de performances. Donc typiquement au niveau du producteur, ça peut être des problèmes de latence réseau entre le broker et le producer. Ça peut être au niveau de la deuxième étape au niveau des brokers, ça peut être un problème de réplication, de synchronisation des répliques qui fait que je verrais pas mon acquittement suffisamment rapidement. Et enfin, au niveau du consumer, ça peut être soit mon traitement applicatif lui même qui est trop long, qui fait que du coup j'ai de la latence dans les évènements. Ça peut également être finalement des problèmes réseau entre le broker Kafka ou des problèmes de disque qui ralentissent mon polling au niveau des brokers. Pour ça, pour pouvoir analyser et trouver la source, la source de ces lenteurs, le mieux est de monitorer via des métriques GMX puisque la plateforme Kafka étant basée sur JVM, tout un tas de métriques GMX sont exposées et le mieux c'est d'utiliser, de pouvoir visualiser où se trouvent nos latences, nos erreurs.Dans notre cas d'usage, on devrait faire un petit exemple avec trois broker Kafka, un facteur de réplication à trois que je cherche à répliquer m'a donné tout sur les trois brookers et un acquittement à all. J'ai constaté que je méttais un peu de temps pour produire des événements. En effet, à la production d'événements qui prend un temps total de 2,3 secondes. C'est ce que m'indique les métriques GMX et ce que je peux dire. Ce que je constate, c'est que je passe 1,5 secondes au niveau de la partie réplication. Donc pour savoir quel est le motif de cette lenteur niveau réplication, je peux faire un zoom sur la partie broker. Donc la partie qui se trouve au milieu. Donc pas le pas des consumers, pas les producers. Donc c'est le graphe d'en dessous et qui m'indique que c'est au niveau de mon broker Kafka deux que je passe ce temps là et que je peux du coup suspecter raisonnablement une contention au niveau du CPU ou des input output disque ram, et cetera.Donc il faut savoir qu'il y a tout un tas de maîtrise GMX qui permet de faire ces analyses là. Le combo ultime c’est l'utilisation de prometheus grafana qui permet d'avoir des dashboard très jolis, de facilement identifier les root causes. Par contre, il faut également faire le tri dans ces métriques parce qu'elles sont tellement nombreuses que certaines peuvent noyer et ne sont pas pertinentes dans l'analyse de ces problèmes-là. Donc à utiliser avec parcimonie, bien faire le tri pour ne garder que les pertinentes. Maintenant que j'ai mis en place des métriques GMX, c'est bien beau, je peux les visualiser dans grafana. Du coup, je suis capable de monitorer ma plateforme, mais avoir des alertes, finalement, c'est encore mieux. Parce que avoir un grafana et des graphiques qu'on utilisera que le jour ou d'autres plateformes a craché, à part de constater que finalement à la belle et bien effectivement craché, ça ne va pas servir à grand chose. Donc le mieux pour ça, c'est de mettre en place des alertes sur les sur les métriques les plus pertinentes, sur les éléments les plus pertinents qui peuvent indiquer toute défaillance avant le crash.On pense notamment au niveau des réplications, à vérifier que toutes nos répliques sont en phase. Vérifier qu’on a un seul actif contrôleur et qu'on n'a pas de réplicats qui serait désynchronisés, et cetera. Donc tout ça pour dire qu'un monitoring, derrière, il faut mettre en place des alertes pour pouvoir prévenir ce genre de problèmes et pas seulement les constater une fois que ça arrive.
Alioune SyMerci Jordan. Qu'est ce qui se passe si on suit tout ce qu'on vient de voir ? On a bien configuré ces acquittements, l’auto commit, on l’a désactivé, on est en monitoring, et cetera et cetera On peut se dire que raisonnablement on a quand même fait des efforts. Ça devrait bien se passer. Et bien non. Qu'est ce qui se passe finalement quand on se retrouve dans des cas d'erreurs lors de la consommation de données ? Rappelez vous le consumer va fonctionner par batch, donc en fait un consumer poll, vous récupérez dix évènements et ensuite vous désactivez l’auto commit. Il faut qu'à la fin du traitement de ces dix événements, vous commitez l’offset de Kafka dans cas pour que la prochaine fois que vous faites consumer poll, vous récupérez un autre batch d'événements. Qu'est ce qui se passe si vous avez ce qu'on appelle un poison pill. Ça va être un événement qui est planqué en plein milieu de votre topic, là qui lui entraîne une erreur quasi systématique. Donc si vous n'avez pas de stratégie spécifique de gestion des erreurs et que vous fonctionnez en mode par défaut en mode YOLO, ce qui va se passer, c'est que vous allez avec consumer poll...Récupérer ce batch de messages là, vous allez traiter un deux, vous arrivez sur le poison pill boum - vous crachez. Vous commitez, pas les offsets. Vous repartez dans Kafka, vous faites poll, vous récupérez le batch, le même batch et ainsi de suite. Rebelotte. Donc vous allez boucler indéfiniment. Et Apache Kafka ne fonctionne pas comme certains brokers que peut être vous connaissez. Ou il y a des stratégies ou automatiquement le broker va écarter un messagen au bout d'un certain temps, nombre de jeux. Ça ça n'existe pas dans Kafka en fait. Et donc du coup de base, si vous vous retrouvez dans cette situation là, vous allez boucler indéfiniment et vous n'allez plus avancer, vous n’ allez plus pouvoir empiler les événements. Donc du coup, ce qu'il faut faire, c'est définir en fait une stratégie de gestion d'erreur. Donc il y a plusieurs stratégies qui sont possibles, dont Kafka gère automatiquement la purge de données. Donc, par défaut, au bout de sept jours, les événements sont purgés.Donc ça, ça peut être configuré. Vous pouvez mettre six ou sept jours, même trois mois si vous voulez. Mais une des premières stratégies qu'il est possible de mettre en place, c'est de ne rien faire et d'attendre la purge de données. Donc attendre que ce batch de message soit purgé et donc du coup vous n'aurez plus à faire aux poison pills, vous pouvez épiller. Ca c'est bien, sauf que vous aurez perdu tout un tas de données, ce qui n'est pas forcément ce que vous vouliez faire. Une autre possibilité, c'est de changer l'identifiant de votre consumer groupe vu que, en fait, l'offset de lecture est lié au consumer group pour que plusieurs consumer groupes puissent consommer sur le même topic. Vous pouvez modifier le d'identifiant du consumer groupe de votre application de telle sorte qu'elle soit considérée comme une nouvelle application. Donc, par défaut, Kafka va commencer à lire à partir de la fin du topic ou au début ça dépend de la configuration auto offset reset. Si vous changez les dimensions du consumer groupe, vous allez recommencer à consommer de la donnée à partir du dernier événement. Vous pouvez changer manuellement l'offset du consumer groupe également. Il y a des API, Il y a une ligne de commande dans Kafka qui permet de faire ça, mais bon, c'est un peu fastidieux, c'est long à faire extra, c'est complexe. Ou alors une stratégie beaucoup plus vertueuse, c'est de définir, de configurer dans Kafka et Handler d'erreur. Donc vous pouvez spécifier Kafka, qu'il va utiliser à chaque fois qu'il a rencontré une erreur, ce qui va permettre en fait de la gérer applicativement dans votre code. En fait, plutôt que de décharger ça côté broker et donc à partir de là, vous pouvez définir un certain nombre de stratégies un peu classiques qu'on retrouve quand on met en place des architectures événementielles. Donc j'évoquais tout à l'heure les dead letter queue. Bah, vous pouvez mettre en place des dead letter topics par exemple pour isoler le présent pill dans un topic d'erreur pour pouvoir le traiter manuellement plus tard.Voilà donc moralité. Kafka c'est bien, mais faites attention, mettez en place des stratégies de gestion d'erreur parce que Kafka ne va pas le faire pour vous, tout simplement. Dernier point d'attention. C'est ce que Kafka permet de faire beaucoup de choses. C'est très intéressant comme Jordan l’a évoqué, c'est assez rapide en termes de performances, c'est top, etc. Pour autant, il faut faire des choix. Typiquement avec Kafka, en fait vous pouvez le configurer pour faire de la latence, donc faire des traitements ultra rapide et très véloce pour être durable pour pouvoir nous assurer une non-perte de données. Vous pouvez le configurer également pour qu'il soit hautement disponible. Ou alors vous pouvez le configurer pour qu'il puisse faire du traitement en masse, donc pouvoir traiter un maximum d'événements à la seconde. Et donc bien évidemment on ne peut pas tout avoir. Donc vous ne pouvez pas configurer Kafka pour avoir toutes ces propriétés là. Au maximum, vous pouvez avoir deux ou trois, mais pas toutes les propriétés. Donc il faut bien identifier vos Use Case et configurer Kafka de façon adéquate de façon adaptée à vos Use Case.Sinon, finalement, vous allez vous retrouver à vous dire, Kafka ne répond pas à mon besoin. C'est pas adapté. Mais c'est peut être que vous n'avez pas bien configuré Kafka par rapport à vos Use Case en fait. Donc là, on vous a juste présenté un aperçu de quelques points d'attention issus de de nos retours d'expérience, il y en a tout un tas d'autres qu'on pourrait évoquer. Mais globalement, le message qu'on voulait vous faire passer, c'est Kafka est assez bien, mais ne vous lancez pas dans l'aventure Kafka juste comme ça, en faisant juste les POC. Étudier vraiment la chose. Informez vous et posez vous les bonnes questions. Typiquement, là, on va lister quatre huit thématiques sur lesquelles il nous paraît important de se pencher avant toute mise en place d'une architecture à base de Kafka. Typiquement, la gestion des topics. Est ce que vous utilisez les bonnes API pour faire vos traitements ce qu'il ne faut pas faire du Kafka stream plutôt que faire des producteurs à la main. Le dimensionnement, le monitoring, et cetera reste donc plein de choses à étudier avant de se lancer juste à corps perdu, à faire du Kafka.Et donc, à ce sujet, Jordan a un petit message à vous passer.
Jordan DesnoësOui, tout à fait. Donc, comme vous le disait Alioune, on intervient en tant que de façon ponctuelle sur des projets qui souhaitent mettre en place Kafka. Et donc pour intervenir, on s’est construit une grille d'audit qui regroupe plusieurs points de contrôle, que ce soit sur les OS, hardware, topic, broker, Kafka. Vraiment on vise très très large. On a 190 points de contrôle et l'idée c'est de s'assurer que rien n'a été oublié et qu'en plus de ça, la configuration qui a été mise en place correspond aux besoins du projet et aux exigences vues avec les clients. Donc, au-delà d'une simple grille d'audit, on s'en sert en plus comme outil pour construire, pour mettre en place le broker Kafka et sa configuration sur notre projet et non pas juste en dernier recours avant de partir en production. L'idée est vraiment de fonctionner de façon itérative pour résoudre les différents points abordés dans cette grille d'audit et arriver en production le jour J avec quelque chose qui correspond vraiment à nos attentes.Et donc dernier point pour continuer la montée en compétence sur Kafka. Il existe trois grands types de moyens finalement. La première, c'est des formations, donc il en existe des gratuites, notamment une, la Kafka concepts fondamentals, qui est proposée directement par l'éditeur confluent qui est gratuite et quatre autres qui sont payantes et sur trois jours. Parmi ces quatre autres, il y en a deux qui sont plutôt orientées développement et deux autres qui sont orientées administration, exploitation, ops autour de clusters Apache Kafka. Et il y a également des certifications que vous pouvez vous faire certifier sur ces deux aspects là. Donc à l'issue de ces formations, vous pouvez vous faire certifier en tant que développeur Kafka ou bien en tant qu'opérateur administrateur Kafka. Et enfin, vous pouvez vous appuyer sur les communautés, les communautés à chaque fois qui sont riches, notamment avec le blog de confluent auquel vous avez trouvé des exemples de Use Case, par exemple de gestion de priorités ou ce genre de choses. Certains l'ont déjà mis en place.Vous allez pouvoir avoir des exemples de mise en œuvre. Et on a un autre exemple de projet communautaire, donc, chez Sopra Steria, on a Sylvain Le Gouellec, qui intervient et qui propose une implémentation de Kafka Stream pour le langage dot dead, puisque celle de par confluent et Apache est à la base fonctionnelle uniquement sur le langage Java. Et enfin, il y a certains événements dédiés à Apache Kafka, comme le Kafka Summit Europe qui va avoir lieu au mois de mai prochain et qui est totalement gratuit et qui se fait cette année de façon virtuelle à cause des conditions sanitaires. Donc vous pouvez y participer comme vous voulez. Donc voilà, on est en train de répondre à certaines de vos questions. N'hésitez pas déjà, si on n'a pas le temps ou si des questions vous viennent de post tech talk, n'hésitez pas à nous contacter sur nos adresses mail. Nous pourrons vous répondre au besoin.
AliouneSy Mouais. Côté question, du coup, il y a quelques questions. Merci à vous déjà d'avoir participé. Donc Jordan a répondu à quelques questions…Notamment. Qui supporte SQL db. Donc ce n'est pas Apache, c'est bien confluent dans la version Community. Donc jetez un coup d'oeil au fichier licence sur GitHub. Je pense que ça ne fait pas de mal. Mais globalement d'un point de vue utilisation, ça ne devrait pas poser de problème si vous êtes pas Amazon.À partir de quelle version supporte les transactions dans Kafka ? C'est la version 0.11. Côté broker. Kafka.Comment on gère la purge des données qui sont persistés sur le disque dur ? Là, il y a plusieurs manières de le configurer et Jordan a répondu aussi suivant la taille ou le délai.Une petite question technique où tournent les traitements Kafka connect ? Est ce que ça tombe sur les brokers ?
Jordan DesnoësPas nécessairement, car il faut savoir que Kafka Connect c'est un procès de sa part, un peu comme vos clients produits sur consumers. Donc libre à vous de le déployer où vous voulez. Donc vous pouvez le déployer sur une machine externe sur le cloud, vraiment comme vous voulez. L'idée étant que cette machine, l'endroit où tournent les traitements ou tournent Kafka Connect, puisse communiquer avec le broker Kafka de destination.
Alioune SyOK, très bien. Pour terminer on prend un peu de hauteur. C'est une question qui est arrivée au tout début de talk. C'est concrètement un événement, ça correspond à quoi le coup peut être derrière ou donner quelques exemples ? Et puis concrètement, ça se traduit comment un body, des metadata ? Qu'est ce qu'on transmet finalement quand on émet un événement ?
Jordan DesnoësDu coup, je vais prendre la question. Un événement finalement, faut faire le parallèle avec un message pour un broker de messages type RabbitMQ. C'est tout simplement un message, donc une donnée qui va transiter dans Kafka. De quoi est constitué un événement ? Comme tu disais Jérôme, y a en effet des metadata qui vont permettre de définir notamment le timestamp du message de l'événement et la partition cible, par exemple, de cet événement là. Donc c'est pour la partie metadata. Et ensuite, il y a une seconde partie qu'on appelle le body, le body de l'événement ou du message, qui est constitué de deux champs. Le premier, c'est la clé. Donc la clé qui est utilisée, notamment pour le partitionnement, comme vous l'a expliqué Alioune précédemment. Etl'autre champ du body, finalement c'est vraiment la value. Donc la value ça va être le corps de message, la donnée qu'on souhaite manipuler et qui peut être du Json qui peut être du XML ou du texte. Tout ce que vous voulez.
Alioune SyOK, merci, mais je vous laisse le mot de la fin.
Jordan DesnoësÀ ton honneur Alioune.
Alioune Sy
Est ce que je suis en direct ? Je ne sais pas. Oui, je suis en direct. Voilà. Merci déjà pour votre participation. J'espère que vous aurez au moins appris deux ou trois trucs ou en tout cas que vous aurez compris que Apache Kafka comporte son lot d'avantages, d'inconvénients, mais surtout son lot de pièges également et qu'il faut sérieusement se pencher sur le sujet. Si vous devez le mettre en place quelque part, je pense que ça résume bien la complexité et puis la puissance de cette plateforme. Donc voilà ce qu'il y avait à dire. On a fait une sélection qui nous paraissait pertinente, mais on aurait beaucoup de choses à dire sur Apache Kafka. Donc n'hésitez pas à parcourir la doc et puis à vous informer sur le sujet. Et puis voilà. Et puis on vous dit à bientôt pour de nouveaux épisodes. Let's talk about IT ! Maintenant, c'est plus tech talks. Merci à vous
Shape The Future : Comment placer le Cloud et le Big Data au service de nos clients ?
Une capacité d'agilité est bien évidemment le maître mot derrière, c'est d'avoir une offre qui soit la plus sécurisée possible et la maîtriser entièrement par des acteurs qui sont Sopra, Steria ou avec notre partenaire OVH. Qu'un acteur franco français pour son expertise, donc en nombre de vous qu'ils connaissent. Donc derrière notre offre. Notre solution ? Quand on parle de cloud souvent, qui est labellisé Open Trusted Cloud avec notre partenaire OVH, qu'est ce que c'est en termes de service ? On va y revenir avec des exemples un peu plus tard. Donc on n'hésite pas à m'interrompre. C'est à des questions.
Isabelle MessinaIsabelle Je suis posée, sûrement oui, pour vulgariser un peu le discours, pour pour les personnes qui sont sûrement au même niveau que moi aujourd'hui. Et pour les experts, n'hésitez pas aussi à poser vos questions de votre côté.
Isabelle MessinaAvoir de la patience parce que ça prend beaucoup de temps. Et administrativement, on ne peut pas dire qu'on est une très bonne adaptation en France pour le coup.
Hugues ValentinDonc là, ça fait partie de la transformation numérique de l'État. À partir de janvier 2022, toutes les collectivités de plus de 3500 habitants devront avoir passé sur une dématérialisation de tout ce qui est demande d'urbanisme. Donc la Sopra Steria sont intervenus de bout en bout à la fois sur la construction des ministères, la construction de l'application qui est développée à partir d'une équipe qui sur Nantes, donc en plus un peu indisciplinée. On leur a mis en place aussi l'infrastructure parce qu'ils avaient des problématiques de délais et ils n'avaient pas forcément ce qu'il fallait chez eux. Donc on leur a mis une infrastructure sécurisée. Suis avec notre partenaire OVH en mode full conteneur et tout ça dans des délais en quelques mois et c'est passé en production depuis l'été dernier avec au fur et à mesure de l'ouverture. Intéressant. Effectivement, quand on parle de ce sujet là, on est vraiment dans une logique agile parce qu'on a développé en mode mât. Déjà, d'un point de vue technique, on a développé dans des technologies agiles, sur des conteneurs et avec une ouverture progressive des services.
Bien évidemment. Là, je ne l'ai pas cité, mais on sait aussi le faire chez nos grands partenaires. Est ce qu'aujourd'hui on travaille quand même pour autant ? Même si je parle de cloud souvent, on travaille avec les grands acteurs du cloud qui sont aujourd'hui Amazon, Azure, Google, qui sont parmi nos grands partenaires. Et on sait aussi faire des choses équivalentes chez ces partenaires là. Donc l'objectif, c'est de pouvoir accompagner nos clients aussi bien sur des problématiques de sécurité vraiment serrées, comme celles du ministère des Armées, jusqu'à des clients qui ont besoin d'une ouverture globale. Des clients qu'on pourrait citer comme des grands distributeurs Auchan, Casino et autres.
Isabelle MessinaAvec lesquels on travaille aujourd'hui.Puisqu'on travaille, en effet , dans tous les secteurs. Tout à fait sur le public dont tu as parlé tout à l'heure. Mais à la Défense.
Donc en fait, c'est pour le suivi d'un dossier patient, d'un patient candidat ou d'un patient. En fait, j'ai donc son dossier complet. Aujourd'hui, on travaille de façon générique sur un projet qui pourrait être déployé bien des fois et par la suite, on est plutôt remarquable. Ambiance. On change.
Hugues ValentinOn fournit des solutions sur étagère parce que le monde de la santé, c'est particulier. Vous comprendrez que nos données ne peuvent pas être. Si on parlait de souveraineté, c'est bien le sujet sur lequel on veut garder nos données et qu'elles partent, pas typiquement aux États-Unis ou chez Facebook ou chez Google. Donc c'est fournir aux acteurs de santé français des plateformes maîtrisée de bout en bout avec des acteurs franco français capables de. Fournir le meilleur des mondes de l'informatique. Effectivement, quand on veut déposer des données, qu'elles puissent être vues par le médecin et après par l'hôpital quand on y va, et cetera et rassembler son dossier patient, son dossier de façon sécurisée, oui. Donc avec une capacité de traitement, si effectivement on puisse analyser et soigner beaucoup plus rapidement avec les symptômes et avoir tout de ce qu'on travaille dans ce qu'on aura, c'est bien là dessus qu'on fournit des solutions. Être capable aussi de rassembler parce qu'on voit ici, on travaille avec des couches d'accélérateurs transverses et de rassembler des données qui sont souvent aujourd'hui.
Oui, j'ai effectivement parlé du présent, mais le futur, c'est là. On compte sur vous aussi pour nous accompagner dans le futur. Et bien voilà, derrière c'était le petit éléphant. Demain, ce qu'on voit avec Amazon, on espère construire le futur avec nos clients et développer encore des solutions de plus en plus innovantes.
Isabelle Messina, Super. Mais c'est ce qu'on fait aujourd'hui de ce que je suis nous a donné en tout cas comme exemple avec les deux thématiques précédentes. Merci beaucoup Hugues. Hum. On va continuer du coup cet hiver. Shape the future avec la deuxième partie. Mohamed Ramdane, responsable de l'offre Data Mohamed qui est en distance, seul avec nous. Je te laisse te présenter. Est ce que tu nous entends ?
La deuxième phase. C'est une phase qui est en cours aujourd'hui, qui est une phase de gouvernance et de la donnée et de sécurité. On travaille sur des sujets de Data Catalog, de Talent Edge. Donc on n'a pas encore démarré et la troisième phase va démarrer fin d'année. Donc c'est une phase de dashboard de visualisation de l'ensemble des produits détenus par un client Android depuis le premier jusqu'à la comparaison du client par rapport à la moyenne de la banque par produit et toujours sur douze mois grâce à Watson. Donc c'est un service qui fait partie de Cloud Pack fondateur. Donc on a procédé à l'analyse des bases de données et au tagging des données en les classifiant. Que ce soit des données personnelles, financières ou autres, et préparer ainsi la mise en conformité avec la RGPD. Donc du coup, si on passe sur le slide d'après. Donc en synthèse, je ne sais pas si Isabelle Huppert, vous avez des questions avant de faire une petite synthèse sur les bénéfices qu'apporte aujourd'hui la date, la virtualisation sur écoute.
Merci Hugues et merci Mohamed. C'était un plaisir de vous recevoir. C'était un plaisir aussi à tous d'avoir participé à cet événement. Merci à tous et très bonne journée.
Sopra Steria - The world how we shape it
Comment faire confiance à l'IA malgré les risques de nos biais sexistes ?
Wendy Penot RousseauBonjour à toute s et à tous, je suis Wendy Penot Rousseau. Caroline, Amélie et moi sommes ravis de vous accueillir aujourd'hui pour ce webinaire consacré donc à la à la relation entre confiance IA et potentiel biais sexiste. Aujourd'hui pour ce webinaire, nous sommes en compagnie d'Amélie Bosca, la Data scientist à Aix en Provence pour Sopra Steria et Caroline Gardet, data Scientist et aussi manager de sa tribu Data pour Sopra Steria. Tout au long de cette présentation, vous pouvez poser vos questions à Amélie et à Caroline et elles y répondront à la fin de leur présentation.Également, n'oubliez pas que vous pouvez interagir tout au long de cette présentation. Sur le klaxoon, vous avez le lien qui a été partagé dans le fil de discussion et également le code qui vous est précisé. Donc Amélie, Caroline, je vous laisse prendre la main. Bonne présentation à toutes et à tous.
Amélie Bosca, Data Scientist chez Sopra SteriaBonjour, donc je m'appelle Amélie, j'ai pour vous présenter un peu mon parcours. J'ai fait une école d'ingénieur généraliste où je me suis spécialisée en dernière année en data science et à la sortie de mon école. Je voulais un métier qui me permette de répondre à des problèmes concrets. Et donc c'est pour ça que je suis venue chercher chez Sopra Steria où je suis data scientist. Aujourd'hui, je travaille à Aix en Provence et j'interviens sur des projets en lien avec la data assurance, avec l'intelligence artificielle et je participe à la construction de solutions qui embarquent de l'IA au développement de ces solutions. J'ai aussi un petit peu de recherche sur des techniques novatrices en IA et enfin, je suis aussi un peu impliquée dans des actions qui visent à familiariser les collaborateurs Sopra Steria à la data science. Donc allez former à les initier et à les accompagner sur ces sujets. Caroline ?
Caroline Garder, Manager des équipes Data Science chez Sopra SteriaCaroline Gardet, mon parcours scolaire remonte à un peu plus longtemps. Mais j'ai fait une école d'ingénieur et ensuite j'étais à l'université pour une thèse en math. J'ai découvert la data science pendant la thèse et j'ai décidé de me reconvertir dans la data science et plus tard dans le conseil. Ça fait quatre ans maintenant que je suis chez Sopra Steria. Je travaille principalement à l'heure actuelle pour le Ministère de Justice, le Ministère de l'Intérieur et le Ministère des Armées qui pilotent des projets tels que des outils d'aide à la décision, par exemple sur le contrôle, le contrôle routier notamment. Donc, comment placer les différents contrôles par rapport au comportement des automobilistes et à l'objectif qu'on veut atteindre ? À l'heure actuelle, je suis manager au sein d'une tribu d'une dizaine de data scientists et donc. Voilà. Nos missions sont très variées. A toi Amélie je te laisse d’introduire le klaxonne.
AmélieDonc pour commencer, on vous propose une petite activité à laquelle un certain nombre d'entre vous ont déjà répondu. Donc la question c'est avez vous confiance en l’IA ? Ben quoi vous laisser encore quelques instants pour ? Pour ceux qui n'ont pas répondu ? Peut être pour vous laisser le temps aussi de vous connecter pour ceux qui n'ont pas pu.
Voilà, donc on vous laisse répondre à cette petite question de départ. Donc pour commencer, on va essayer d'expliquer un peu d'où viennent les biais dans l'IA puisque c'est le sujet de la présentation aujourd'hui. Puis on évoquera ce qu'on peut faire aujourd'hui pour des IA qui sont déjà construites. On se demandera aussi ce qu'il aurait fallu faire avant leur construction. Et enfin, la question comment avoir confiance ? Où on parlera notamment du sujet de la certification de l'IA ? Donc tout d'abord, on va commencer avec un fait divers qui a fait la une des journaux. Il s'agit d'une polémique sur les algorithmes de reconnaissance faciale qui serait raciste et sexiste. Donc ce fait divers, en fait, il correspond à une étude qui a été menée, qui s'appelle Gender Shades, dont le but est d'analyser différents algorithmes de reconnaissance faciale qui ont été développés par plusieurs sociétés différentes et d'y déceler d'éventuelles traces de sexisme et de racisme. Donc, le tableau que vous voyez, il affiche le taux de réussite de ces algorithmes. Et si on regarde par exemple la ligne de l'algorithme d'IBM, et bien on voit qu'il y a plus de 10 % d'écart en performance entre un homme noir et un homme blanc.
Donc d'une part, il est raciste, mais on voit aussi qu'il y a plus de 20 % d'écart entre un homme noir et une femme noire par exemple. Donc il est également sexiste. Et en tout entre les deux cas extrêmes, donc pour ce cas là est l'homme blanc et la femme noire. On a plus de 34 % d'écart. Donc ce compte, ce conseil est assez accablant puisque ces algorithmes sont à la fois racistes, sexistes et en plus avec une marge qui est quand même très très importante. Donc ce type de faits divers est fait souvent à la une des journaux et c'est notamment le cas aux Etats-Unis où l’intelligence artificielle est largement utilisée dans la société, donc par exemple pour la reconnaissance faciale, mais aussi pour des faits de discrimination à l'embauche par exemple. Avec Amazon, on avait un algorithme qui donnait une note de un à 5 à 1 cv pour un poste donné et on s'est rendu compte que pour des emplois techniques, comme par exemple une développeuse web, les femmes, elles, étaient systématiquement écartées.
Un autre fait divers. C'est un algorithme à l'hôpital à propos de programmes de santé, de programmes de soins avec des personnes qui étaient choisies pour ces programmes en fonction de leur origine ethnique. Et donc, évidemment, vous en doutez, ça favorisait plutôt les personnes de couleur blanche. Donc, l’IA où elle intègre, elle intègre des biais dans les résultats qu’elle produit. Et lorsque ces biais sont du racisme ou du sexisme, cet usage devient très problématique et ça accentue les inégalités. Par exemple, on peut imaginer que la reconnaissance faciale, ça pourrait être utilisé pour arrêter quelqu'un pour un crime et dans ce cas, si on a plus de chances d'erreur sur certaines catégories de population, ça serait dramatique. Et dans le cas des cv, les femmes n'auront jamais l'occasion d'accéder à des postes techniques. Donc maintenant, nous allons essayer de comprendre ce qui s'est passé, d’où viennent ces biais ? Et bien pour comprendre, nous allons commencer par expliquer comment ces algorithmes d’intelligence artificielle sont construits.
Pour ça, on a un principe général, c'est le principe d'apprentissage. On va essayer d'expliquer un peu ce qu'est cette construction de modèle par apprentissage. Donc, par exemple, imaginons qu'une société, elle prépare un recrutement pour un poste. Au hasard, elle veut embaucher un data scientist. Eh bien, on va avoir des dizaines, voire des centaines de cv qui vont arriver auprès du service RH. Le RH lui reçoit ses cv et qu'est ce qu'il va faire ? Il va trier ses cv et il va essayer de présélectionner qu'un nombre réduit de candidats pour ce poste et cela, ils décrochent un entretien. Et nous ce qu'on voudrait c'est automatiser cette présélection et pour ça on dispose d'une base de données de cv de data scientists avec l'information pré-sélectionnés ou non par le RH qui avant on faisait ce tri là à la main. Donc on a des données qui sont étiquetées. En data science on dit labellisés. Vous le voyez ? Par exemple, on voit que Clément, il a été sélectionné. Amélie, elle a pas été sélectionnée.
Caroline, elle a été sélectionnée et donc ces données là, c’est-à-dire les cv, plus les étiquettes on va les injecter dans un modèle. Alors qu'est ce que c'est, un modèle ? C'est tout simplement une fonction mathématique qu'on essaye d'ajuster au mieux. Et cette phase d'ajustement, c'est ce qu'on appelle l' entraînement. Donc on cherche le modèle qui associe le mieux les cv avec leur étiquette, c'est à dire le modèle qui fait le moins d'erreurs. Et comment l'algorithme procède à cette recherche. C'est avec le principe qu'on appelle de l'essai de l'erreur. C'est-à-dire que si on caricature un peu, on a un modèle de départ, on lui injecte les cv, on regarde de combien il se trompe, on a juste un petit peu. Et puis s'il fait plus ou moins d'erreurs, on ajuste encore un peu. Et petit à petit comme ça, on continue ce processus jusqu'à ce que l'algorithme fasse de moins en moins d'erreurs. Après cette phase d'apprentissage, on a un modèle qui est figé et on dispose d'un algorithme qui s'est associé les cv avec leurs étiquettes.
Mais nous, ce qu'on veut en réalité, c'est pré-sélectionner nos cv actuels, c'est à dire les nouveaux cv, ce qui n'était pas dans la base de donnée de départ et dont on veut déterminer la nouvelle étiquette pour notre recrutement. Donc pour cela on injecte par exemple le cv de Mehdi dans le modèle. Et puis le modèle nous donne l'étiquette. Donc dans ce cas là, Mehdi, il a été sélectionné. Et l'algorithme, il a appris la tâche sur un ensemble de données qui étaient existantes. Et ce qu'il est capable de faire, c'est de généraliser ce qu'il a appris à de nouveaux cv qu'il n'a jamais vu. C'est ça le vrai but de l'apprentissage. Donc vous voyez bien avec cet exemple que la base de départ de l'algorithme, ce sont les données qu'on lui injecte en apprentissage et il va généraliser ce qu'il y trouve. Et si c'est des biais, il va les généraliser aussi. Donc imaginons maintenant que la base de données, elles correspondent au cas que vous voyez à l'écran. Donc par exemple le cas un on a beaucoup plus de cv d'hommes que de femmes.
Eh bien dans ce cas l'algorithme va être beaucoup plus performant sur les hommes parce que c'est un gars qui connaît beaucoup mieux. Il va apprendre une règle simplifiée pour les femmes en disant que si vous êtes une femme, vous n'êtes pas sélectionné parce que c'est un cas marginal. Et c'est typiquement ce qui s'est passé avec la reconnaissance faciale. Comme les femmes noires par exemple, elles sont sous représentées dans la base de débat et forcément, l'algorithme est moins performant sur sur ce type de profil à la fin. Maintenant, si on prend le cas numéro deux qui est un petit peu plus subtil, on a autant de cv d'hommes que de femmes dans notre base d'apprentissage. Mais sur ces cv, la majorité des cv qui ont été sélectionnés ce sont ceux d'hommes. Et bien dans ce cas, l'algorithme va apprendre que les hommes sont à privilégier, que les hommes sont le profil idéal et donc ça c'est une explication possible pour pour les programmes de soins dont on a vu tout à l'heure aussi. C'est-à dire que par exemple, on peut considérer que les minorités, typiquement aux États-Unis, elles sont, elles sont globalement plus pauvres, donc elles mettent plus de temps avant de décider à se soigner.
Donc elles ont globalement des maladies plus graves quand elles s'inscrivent dans le programme de soins et donc le programme de soins, ils échouent plus souvent. Et donc l'algorithme va apprendre que cette catégorie, elle, n'est pas à privilégier puisque les programmes ont échoué plus souvent. Donc c'est une explication. C'est peut être ce qui s'est passé dans ce cas là. Et donc ce qu'il faut bien comprendre, c'est que pour l’algorithme, ce type de modèle il est correct et en fait ces modèles, ils sont performants sur la base de données qu'on lui donne parce qu'il fait peu d'erreurs, mais pour autant ils sont biaisés et c'est bien le c'est bien le problème. Donc les données qu'on lui injecte en apprentissage. Ça joue un rôle crucial, car l'algorithme va reproduire ce comportement observé et il va même exacerber bien souvent malheureusement, et on le voit avec le modèle simplifié et avec les femmes qui sont pas retenues. Donc, le premier élément de réponse, et pas des moindres, à la question d'où viennent les biais ? Ils viennent des données.
Mais en réalité, les données, elles, sont issues de notre quotidien. Elles sont issues de nos process, par exemple avec les cv. Par le passé, il y a eu plus d'hommes embauchés que de femmes à ce poste. C'est un fait. Et donc elles représentent ces données, elles représentent notre société. Donc finalement, les biais, ce sont directement les nôtres. Les données ne sont qu'un intermédiaire pour le modèle d’IA d’analyser notre société. Donc aussi on a d'autres facteurs, bien sûr, qui conduisent à ces biais. On l'a vu, la société, elle comporte des biais, effectivement. Mais l'humain aussi. Il est biaisé chacun d'entre nous et c'est naturel, c'est normal. Et sans surprise, le data scientist, il n'échappe pas à cette règle. Comme chaque humain, il a une histoire, il a une éducation et ses propres biais se retranscrivent forcément dans son travail. Et même si on en a conscience, ils sont inévitables, même si le fait d'en avoir conscience, ça aide à les réduire.
Bien moi, si demain je fais passer un entretien avec quelqu'un et que je vois sur son cv qu'il a fait la même école que moi, forcément je vais être, je vais être influencé, c'est naturel. Mais pourtant, si autour de moi j'ai des collègues qui ont un parcours différent, eh bien, je vais être plus ouverte à considérer d'autres profils parce que je fais confiance typiquement à ces personnes avec qui je travaille et je vois que leur travail est adapté. Finalement, si on décide ensemble de recruter une personne pour le poste, la décision, elle, va être plus impartiale parce qu'on va venir d'horizons différents. C'est pareil pour les décisions qui sont prises pour construire un modèle d'IA, parce que la seule différence, c'est que les biais, ils peuvent être un petit peu moins évidents à voir que sur l'exemple que je vais vous donner. Et donc c'est encore plus difficile de se remettre en question. D'où l'intérêt d'avoir des équipes qui sont très diversifiées, avec des personnes qui viennent de milieux sociaux différents, qui ont fait des études différentes, des hommes, des femmes.
Le tout pour avoir une vision plus large et réduire ces biais. Bien sûr, ce que je viens de vous dire, ça s'applique pas qu'à la data science, mais quand on manipule des outils comme je viens de vous l'expliquer, qui exacerbent nos biais, c'est encore plus important d'en avoir conscience. Et donc je viens de dire que quand on manipule des outils, eh bien oui, justement, l'IA c'est un outil d'où ne viennent certainement pas les biais de l'IA en elle même qu'on fait parce que l'IA elle est en aucun cas elle est intrinsèquement raciste ou sexiste. C'est juste un outil. Encore une fois, c'est juste une fonction mathématique et donc la seule chose qu'elle fait, c'est suivre le sens des données qu'on lui montre. Et enfin, les utilisateurs peuvent aussi introduire des biais, c'est-à-dire potentiellement tout le monde en fait. Et quand je dis ça, je pense à un exemple particulier qui est un peu un cas extrême, c'est celui de ce qu'on appelle les IA auto apprenantes. Par exemple, on avait un chatbot Tay qui était un chatbot Microsoft qui a été mis en service pour avoir des conversations avec des internautes et s'améliorer au fur et à mesure des interactions et des réponses, typiquement pour s'adapter au langage de la personne avec qui il converse.
Et au final, ce qui s'est passé, c'est qu'il a été mis en service et en moins de 24h, les utilisateurs lui ont appris des propos violents. Et à la fin, le robot postait des tweets avec des injures et des propos nazis. Donc ça, c'est un cas où l'apprentissage est incessant et c'est tout le problème. On a vu que les données dans C sont les données d'entrée qui posent problème et là, dans ce cas là, les données d'entrée elles, sont en continu. Donc on n'a pas de modèle qui est figé, contrairement à ce que à ce que je vous ai expliqué tout à l'heure. Et donc, avec ses IA auto apprenantes, on n'a pas de barrière pour prévenir des mauvaises données en entrée. Et ça, ça peut être typiquement très dangereux. Donc ça, c'est un exemple extrême. Mais plus généralement, ce que je veux dire, c'est que l'utilisation de l'IA, la bonne utilisation d'IA, c'est de la responsabilité de chacun. Encore une fois, l'IA, c'est un outil.
On peut l'utiliser à des fins racistes, sexistes, comme tous les autres outils. Et c'est à nous, utilisateurs, d'être vigilants et de nous poser les bonnes questions. Donc maintenant que nous avons vu d'où pouvaient provenir les biais, on va s'intéresser aux manières de pallier ces biais lorsqu'ils apparaissent. Et pour ça, je vais laisser Caroline prendre la suite.
Caroline GarderTrès bien. Donc, comme Amélie vient de le dire, il y a toute une série de bonnes pratiques qui ont été mises en place et acceptées dans la communauté pour essayer de pallier ce problème de biais. Et le premier, les premières bonnes pratiques c'est la maîtrise du jeu de données, des connaissances qu'on peut avoir sur chacune des données qu'on manipule. Et la meilleure façon de connaître son jeu de données, c'est d'aller parler avec les experts du domaine métier concerné comme les data scientists. Donc on est spécialiste des données, rarement des métiers sur lesquels on les applique, donc ils vont pouvoir nous apporter un nouveau point de vue sur comment était récoltées des données commençant elles sont utilisées et quelles sont celles qui sont les plus pertinentes pour le problème qu'on veut résoudre ? De façon assez naturelle, on cherche à automatiser un maximum la recherche de biais dans les algorithmes. Ça ne dépend pas que du data scientist, c'est-à-dire qui a une méthodologie dans la façon de concevoir qui c'est de chercher les populations sous représentées. Alors après ? Quand nous les cherchons toutes, on va pouvoir ensuite analyser et savoir si cette population est sous représentée, parce que notre jeu de données est mauvais ou parce que mauvais, incomplet. Et donc il va falloir augmenter ces données et pallier aux problèmes. Où est-ce que la population est sous représentée, parce que finalement on peut rechercher des anomalies dans un réseau électrique et que heureusement, les anomalies sont moins nombreuses qu'une situation normale ? Donc. Toute cette automatisation est bien, mais vous avez compris, il faut analyser derrière et pour analyser, il faut éviter les effets BlackBox. On ne prend pas un algorithme sur étagère qu'on applique comme ça sur des données. C'est pratique parce que je veux dire, Google et autres GAFA produisent des algorithmes hyper puissants qu'on a et les mettent à disposition sous forme, qui sont très faciles à utiliser.
Maintenant, il faut savoir comment ils fonctionnent et surtout sur quelles données ils s'appuient. Par exemple, si vous en entraînez un, je reprends l'exemple précédent du tri des cv. Si vous entraînez votre, vous prenez tous vos cv de façon brute, vous allez passer dans un modèle de traitement automatique du langage et vous vous apercevez qu'il est super pratique. Il est super performant mais s'appuie par exemple sur une donnée qui ne vous intéresse pas du tout. C'est pas du tout, pas au moins pas pour la premier tri de cv, c'est les loisirs de la personne. Bah si vous avez pas été cherché et analysé votre votre algorithme, vous auriez jamais trouvé qui s'appuyait sur les loisirs et que finalement il est hyper performant. Mais ça ne vous donne pas les bases. Il ne s'appuie pas sur des choses pertinentes. Donc dès que vous allez lui donner des nouveaux cv, peut être que la personne convient très bien au poste, mais pas de chance, c'est pas le bon loisirs et donc le passera par l'entretien, le stade de l'entretien.
Ça serait quand même dommage. Donc bien comprendre sans son algorithme sur quoi ça s'appuie ? Comment il fonctionne ? Nécessaire. En outre, une autre bonne pratique, c'est mettre en place des systèmes de surveillance des données en entrée et des résultats en sortie. Pourquoi je vous dis ça ? On pense toujours à l'utilisateur idéal, c'est-à-dire celui qui sait exactement comment il doit se comporter avec un, une solution d'IA, une application, peu importe. Sauf que ce n'est pas le cas. Souvent, les données du monde réel sont différentes des données qu'on a normalisées, standardisées en entrée pour entraîner les algorithmes. Donc, surveiller l’entrée, ça veut dire s'assurer que la majorité des utilisateurs vont se servir correctement de votre solution et donc les données en entrée sont conformes. Et tous ceux qui ne l'utiliserons pas bien seront souvent redirigés en leur disant “Non, il faut rentrer les ça et ça ou faut faire ça sans ça avant de nous en servir”, soit ils seront redirigés vers un ça sera traité, ce sera pas laissé au hasard de la réponse de l'algorithme.
Et enfin prendre le temps de tester à grande échelle. Parce qu' on peut penser à toutes les erreurs, possiblement de mais on les aura jamais. Donc prendre le temps de tester à grande échelle, confronter la solution aux utilisateurs, c'est ce qui permet d'apprendre à l’infini avec le feedback amélioré. La solution, c'est ce qui permet d'avoir une solution la plus efficace, éthique possible. On a mis en place toutes ces bonnes pratiques tout au long du projet IA. Donc là c’est une modélisation d'un projet qui part de la compréhension du besoin métier en passant par la conception du modèle jusqu’au déploiement et à la supervision de l'application. Et on voit que chacune de ces bonnes pratiques apparaissent à chaque étape. Donc inclure des experts métiers de la compréhension des besoins métiers, mais aussi, par exemple, une fois qu'on a appris à l'étape quatre, une fois qu'on a notre modèle, qu'il a appris qu'on l'a évalué, qu'il est bien performant et revenir vers le métier, pour évaluer la pertinence de ce qu'on a obtenu et évaluer l'ergonomie de la solution qu'on a pensé.
AmélieEvaluer est-ce que l'erreur qu'on a est acceptable ? Donc revenir vers les métiers, même au cours du projet. Ou encore une fois qu'on a supervisé cela, vous aurez les bonnes pratiques de tests à grande échelle des systèmes de surveillance. Donc ça, c'est des bonnes pratiques, mais on est en réaction. Le projet est déjà parti, on sait ce qu’on veut faire, on est deux dans la phase, on a les données dans les mains et c'est parti. Mais le mieux c'est d'anticiper. Donc c'est une notion qui est en cours de définition. On entend beaucoup parler actuellement. Pas seulement pour l'IA. C'est l'éthique by design. Donc c'est une tendance qui a été lancée par la privacy by design et le RGPD. C'est penser une application dès son design à respecter certains principes. Donc pour la privacy, c'était respecter des principes de données personnelles et l'éthique bien sûr. Respecter les principes éthiques. C'est pas encore figé comme mais comme comme concept, ça fait partie des notions qui sont dans la plupart des exploratoires dans les diverses sociétés actuelles.
Caroline Et c'est se poser des questions comme pourquoi est ce que je conçois cette IA, à quel endroit je vais utiliser l'IA ? Pourquoi faire exactement dans ce cas là ? Si je pars avec l'idée de l’IA quel l'erreur est acceptable. Quel impact en cas d'erreur sur l'utilisateur ? Sur le, le client pour qui on fait le produit à base de l’IA ? Quel est son niveau de formation ? Quelle va être la portée de mon produit et avec quel impact en cas de succès ? Donc tout ça, ce sont des questions qui sont en cours. Et pour qui semblent abstraites. La photo, commençons par l'élément un. La photo est évidemment un risque de biais sexiste puisqu'on la reconnaît quand même. Ou bien un homme ou une femme, donc enlèverait tout simplement lors d’un traitement. Pareil pour le non. Il existe à l'heure actuelle une majorité des banques de non et donc on sait si une femme ou un homme. Il existe d'ailleurs déjà des applications qui permettent, à partir du nom et du prénom, de retrouver le genre de la personne pour compléter des formulaires administratifs.
Donc, c'est tout un élément qu'on enlèverait aussi et qui n'est pas vraiment nécessaire pour le pour le tri des cv. Donc pas besoin de l'altérer. Un data scientist est un terme en anglais. On a la chance que ce soit ni féminin et masculin, donc on gardera tel quel puisqu'en puisque c’est la base de la recherche du tri. Le baccalauréat scientifique. Donc là comme ça, le nom est tout simple, aucun problème, c'est ni féminin ni masculin. Et à l'heure actuelle comme au baccalauréat scientifique, est quasiment la même proportion d'hommes et de femmes. Euh, ça on peut pas en déduire si le candidat a plus tendance à être un homme qu'une femme. Donc pareil, on garderait tel quel. Je suis passionné par l'intelligence artificielle en cinq. Donc là il y a un risque. Alors pourquoi il y a un risque ? Mais ce n'est pas totalement. Ça va dépendre du modèle que vous allez utiliser à repérer comme données. Mais si vous en êtes, si vous utilisez un ancien modèle de traitement automatique du langage qui va, qui ne gardera que la racine des mots.
Finalement, c'est un modèle qui va permettre d'enlever l’accord, qui est fait sur passionné et ne garder que le passion en fait, et donc ça va dégenrer. Mais cette phrase est genrée. On pourrait en déduire que le candidat est une candidate. Maintenant, les nouveaux modèles ont tendance à ne plus à ne plus modifier les mots, donc il y aurait risque de biais. Et donc il faudrait probablement dégenrer le passionné, un vendeur ou tout simplement il faut dégenrer cette phrase. Le six, pratique du football en club depuis cinq ans au SCSCF. Donc la pareil. Une phrase qui est assez intéressante dans le sens où le SCSCF est un club de foot féminin. Donc on sait qu'il y a fort qu'il y a énormément de chances que si quelqu'un pratique du foot au SCSCF est une femme, mais en même temps le foot est majoritairement pratiqué par les hommes, donc ce serait probablement aussi. Alors là, dans notre cas de tri cv pour la première phase, ça nous intéresse pas vraiment les loisirs.
Donc on aura plus tendance à enlever les loisirs et qu’à les garder. Mais il faut savoir que si vous mettez que la pratique du foot dans un club de foot féminin peut permettre de retrouver si vous êtes un homme ou une femme. Et enfin, participation à l'édition 2019 du Trophée Roses des Sables, dont fait partie le Trophée Roses des Sables, étant une course réservée aux femmes forte probabilité que si vous y participer, vous soyez une femme. Donc voilà, comme je l'ai dit dans une phase de premier tri de cv, on va se demander si vraiment les loisirs sont intéressants ou pas pour cette première phase et donc on va probablement les enlever pour éviter tout, tout biais de genre. Et enfin, je vais terminer par la certification et l'homologation. Donc avoir confiance dans un produit si facile si on a une certification. Aujourd'hui, vous achetez des jouets et avec la norme CE, vous achetez de la nourriture qui a une certification ou un label AOC, AOP et IGP et vous êtes sûr que ces produits qui sont certifiés sont sûrs que pour obtenir ce label, il faut savoir qu'il y a eu des tests.
Une organisation indépendante a vérifié que les produits étaient bien d'origine contrôlée, et cetera et cetera. Donc vous faites confiance à ces produits quand vous les achetez. A l'heure actuelle, il n'existe pas de certification ou d'homologation pour l'IA. Ce sont des projets de R et D qui sont en cours et qui ne verront probablement pas le jour avant au moins cinq ou six ans. Notamment sur les problèmes d’explicabilité et de très très très très gros modèles qui font qui sont des des énormes verrous scientifiques pour faire une homologation. Donc à l'heure actuelle, avoir confiance dans un produit d’IA ca vient généralement de de tout, de même de deux façons de penser que tout le monde les utilise. Donc finalement, j'ai tellement pris l'habitude que je ne me pose même plus la question. J'ai confiance, je l'utilise tous les jours et ce n'est pas la meilleure. Ce n'est pas la meilleure façon de penser. Le mieux c'est en fait, ou alors c'est. Je me suis fait une conviction sur l'outil, j'ai été chercher comment il fonctionne, comment il a été conçu.
Donc je sais que je peux lui faire confiance ou pas confiance, c'est pas facile. Se faire faire une conviction sur un produit à base d'IA quand on n'est pas spécialiste de l'IA, c'est un processus qui est difficile parce qu'il faut lire de nombreux articles, il faut croiser les informations et on va être honnête, on n'a pas forcément le temps de le faire à chaque fois ou ils oublient d'ailleurs. Donc, si ça repose sur les concepteurs de la solution d'IA qui doivent faire prendre conscience alors, ou à leurs futurs utilisateurs ou à leurs utilisateurs à l'heure actuelle qu'une solution d’IA a ses limites. C'est très très pratique. Ça permet de faire des choses qu'il n'est pas possible de faire jusqu'à maintenant, mais il y a des limites. Il faut être formé à son utilisation. Un outil d'aide à la décision ? Ça donne une prédiction, ça donne une information avec une probabilité comme indicateur de fiabilité et une probabilité. Eh bien, qu'est ce que ça veut dire ? Si demain il y a 70 % de chances qu'il pleuve ?
Ça veut dire quoi ? Ça veut dire qu'il faut que je prenne mon parapluie probablement. Mais ça ne va pas me dire s' il va pleuvoir beaucoup aussi, pas beaucoup. Si ça va être des averses, s’il va pleuvoir en continue. Donc il faut vous expliquer le produit qu'on délivre. Il faut former aux limites et expliquer ce que ça fait. Donc revenir à un exemple, qu'on a utilisé tout au long de cette cette présentation, c'est le tri des cv. Si vous avez construit une solution d'IA de tri des cv pour un poste de data scientist qui se base sur le niveau d'études, l'expérience, la langue parlée et l'esprit d'équipe, disons. Et que le à 50 % c'est le niveau d'études qui compte et que 30 % sont des expériences similaires. Vous savez qu'en tant que RH, si on vous a expliqué tout ça, que cet outil ait été conçu pour faire le tri pour le poste que vous avez demandé, si jamais vous faites un autre post, soit il faudra reparamétrer l'outil, soit vous même, sinon inutile.
Permet soit par des data scientist. Est ce que je prends un exemple ? Si jamais vous faites un nouveau poste pour un niveau d'étude différent ? À ce moment, il sera plus du tout adapté puisque vous l'avez entraîné un certain niveau d'études. Et donc si la RH utilise cet outil pour faire son tri sur un autre cv que ca lui remonte que des cv qui ne correspondent pas à sa recherche, elle va arrêter d' utiliser l'outil puisque ça n'aura remonté que que des cv, donc ça n'en a pas besoin. Donc elle n’aura plus de confiance en l'outil. On va perdre un utilisateur très clairement. Donc c'est nécessaire. Et c'est à son concepteur, Data Scientist, de faire prendre conscience aux leurs utilisateurs qu'il faut qu'ils soient formés et qu’il y ait des limites. Donc en conclusion, on a vu que les biais des modèles d'IA proviennent principalement des données qu' on utilise pour leur faire apprendre qu'elles à l'heure actuelle y des méthodes à base de bonnes pratiques qui permettent de pallier ce problème, mais que le mieux c'est d'anticiper. Donc ça, c'est un travail en cours qui portera ses fruits probablement d'ici à la fin de l'année et qui permettront de designer l'outil, qu'il soit éthique, webdesign, éthique et enfin qu'il faut responsabiliser les utilisateurs.
Donc il faut que les éditeurs de solutions et de disques produisent de la documentation qui explique au moins à leurs utilisateurs et que les utilisateurs prennent leur responsabilité pour que quand ils utilisent l'IA, ils reconnaissent les limites et sache comment l’utiliser. Voilà. Soit tout pour nous. Donc s'il y a des questions maintenant ?
Oui, bien sûr, On a reçu quelques questions. On va les traiter dans leur ordre d'arrivée. Et puis également, si vous avez d'autres questions qui vous viennent, n'hésitez pas à nous les partager. Une première question de Romain. Pourquoi ne pas pour définir les modèles IA et réduire un possible biais, entraîner autant de cv d'hommes que de cv de femmes ?
Caroline Mais cela dépend de la récolte, par exemple pour les postes de, si j'allais dans un service d’IT et que je leur demandait leur cv de des candidats qu'ils ont reçus pour les postes précédents, il y aurait 80 % 90 % de cv qui viennent d’homme. Parce qu' à l’heure actuelle il y a autant, il y a beaucoup plus de cv d'hommes. Ce sont des hommes qui postulent pour des postes IT que des femmes. Donc il faudrait que je rééquilibre mon jeu de données. Donc il existe des méthodes pour équilibrer le jeu de données, mais de façon brute. La plupart des jeux de données sont déséquilibrés. Je sais pas si ça répond à la question.
Wendy
On laisse ce Romain revenir vers nous si ce n'est pas le cas. Une question de Damien. Peut-on dire à la machine que certaines caractéristiques ne sont pas en lien avec la sélection ?
Caroline Mais quand, Amélie n'hésite pas… Je répond aux questions et quand on entraîne un algorithme, par exemple sur un cv, quand on ne veut pas mettre certains données, on les élimine tout simplement du jeu d'apprentissage, c'est à dire qu'on va, on va enlever les données qu'on ne veut pas, qui prennent en compte tout simplement. Ou alors si on veut quand même s'appuyer dessus, mais enlever le genre, on va les standardiser ou les anonymiser.
AmélieJuste pour rebondir, je voudrais être sûr que la question de Damien, elle n'est pas plutôt dans le sens de savoir si on pouvait indiquer à la machine qu'elle devait omettre certaines parties des données qu'on lui montre et que ce serait plutôt dangereux de faire ça et ce qu’a expliqué Caroline, c'est justement ce qu'on fait plutôt, c'est d'éviter de lui montrer ce qu'on ne veut pas qu'il voit.
CarolineAh, tu veux dire enlever certains de ses utilisateurs ? C’est ca, par exemple ? Dans un dans un cas de cv déséquilibré, on enlèverait la moitié des cv de DOM.
AmélieOui, c'est ça, On va repartir à la machine. Il y a par exemple 30 % de que tu ne dois pas prendre en compte. Non, non, on va plutôt en amont traiter le problème au niveau du jeu de données directement. C'est pas la machine à qui on va expliquer qu'elle doit traiter dans un certain sens.
WendyMerci à toutes les deux. Une question de Stéphanie. Devons nous conclure que nous devrions avoir un cv en anglais sans photo et avec la première lettre de notre prénom seulement ?
Caroline GarderAlors bonne question. Le cv en anglais, ça dépend où vous postulez, mais je vous conseille pas parce que le niveau d'anglais à l'heure actuelle dans certains espaces c’est pas extraordinaire, donc non. La photo. Alors la, on parle des cv pour le tri de la machine. C'est-à-dire que ca doit être impartial puisque justement, on va attendre de la machine qu'elle soit impartiale. Ensuite, il faut garder à l'esprit que vous cv vont être vus par des RH et par des clients, par des opérationnels, donc par des humains et que donc plus votre cv sera reflètera votre personnalité, plus il y a de chances que l'humain enfin qui lit votre cv le sélectionne. Donc non, moi je vous conseillerais de faire un cv comme est attendu selon les guidelines de l'endroit où vous postulez.
Merci Caroline. Une question de Damien. De la même façon qu'il y a un permis lorsqu'on conduit un véhicule. Pourrait on envisager une sorte de permis attestation pour l'utilisation d'une IA ?
AmélieHoula, ca c’est… Ca on pourrait le faire si on avait ce qu'on appelle la l'homologation c’est-à-dire par exemple, on pourrait faire une poignée dans l'administration française. On utilise que les IA qui sont certifiées parce que ce sont des critères, des normes, des standards. Donc ça, ça pourrait être fait. À l'heure actuelle ça n’existe pas. Donc ce serait difficile de légiférer sur un permis d’IA ? Maintenant, il faut savoir que la loi française est relativement bien faite et que dans toutes les systèmes dits critiques ou les systèmes importants, l'utilisation de l'IA est très réglementée. Donc, par exemple, moi quand je fais des systèmes d'aide à la décision, ça passe toujours par un utilisateur humain qui prend la décision à la fin. Donc, les endroits où ça a vraiment de l'importance, où la décision a de l'importance. L’IA ne décide pas encore d'elle-même. Ensuite, permis d’IA, l’IA est partout. À l'heure actuelle, pour ouvrir votre téléphone, pour vous proposer des pubs, pour vous proposer des programmes Netflix sur Amazon, pour mettre des Vélib à la bonne place dans Paris, il y a de l’IA absolument partout.
CarolineDonc un permis d’IA ce serait un peu. Il y en a déjà quasiment partout du coup.
AmélieVoilà, je ne sais pas si ça pourrait être envisageable pour certains déjà dans des cas très spécifiques, mais c'est surtout ce qui est important de retenir au-delà du mot permis, c'est le fait qu'il y a une formation derrière. Alors après, est ce que cette formation est certifiante ? Est ce que est ce que je te donne derrière, un droit d'utilisation ? C'est une autre question, mais en tout cas sur l'aspect formation. Oui, complètement. Ça devrait être oui.
WendyUne question de Louis, pour reprendre l'exemple du chatbot Tay. Qu'est ce qui aurait été bien de faire pour filtrer les données qu'il reçoit des utilisateurs ?
Alors là, c'est compliqué. Est ce que tout l'intérêt d'un chatbot c'est l'interaction en temps réel ? Donc si on commence à filtrer ce que ce que les utilisateurs lui disent, mais ça va ralentir, ce sera plus du temps réel. Donc le but est de faire un chatbot qui comprend le langage humain. Et donc ils s'étaient dit que, au lieu de labelliser, d'entraîner, de créer un jeu de données énorme, ils allaient mettre le chatbot en ligne, et puis, à force de parler avec les gens, ils allaient s'entraîner à comprendre le langage humain en parlant avec les gens. Internet étant ce que c'était le les gens l’ont rendu misogyne et tout ce que vous voulez. Donc à mon avis, cette façon de faire, c'est la façon de faire qui était inadaptée. On ne peut pas laisser l' entraînement d’un modèle sans barrière puisque là c’était vraiment sur internet. Donc en faisant comme ça on était sûr d’aller à l'échec. Je ne vois pas comment s'en aura été autrement.
Il fallait y penser, je ne les blâme pas, mais c’était pas encadré. Donc pour faire comprendre à chatbot le langage humain c’est de créer soi-même son dataset, c'est créer à l'heure actuelle, par exemple, les grandes boîtes comme Google et grands GAFA, Google, Amazon, Facebook, et cetera utilisent Wikipedia. Wikipedia a entièrement mis à disposition sa base de connaissances avec des articles labellisés et donc ils entraînent pour comprendre les langages et les interactions. Wikipedia ou des livres, voilà ce qui permet d'encadrer le ce qui a appris le robot. Toute la question si c'était est ce qu'on aurait pu censurer les gens au fur et à mesure ? Non, parce que son nom va enlever le l'interaction en temps réel avec le robot. Est ce qu'on aurait pu faire autrement ? J'ai un doute.
AmélieMais surtout que ce bot est vraiment à vocation éducative. Donc l'idée, c'était justement de le laisser libre de ses interactions avec les utilisateurs. Donc je pense que ce n'était même pas la philosophie du projet en plus.
Merci à toutes les deux. On continue les questions. Comment justifier qu'un jeu de données est suffisamment juste et que tous les biais vont pouvoir être traités et évités ?
AmélieOu alors tous déjà si c'est pas possible, ça l'est assez clair déjà de ce côté là. À ce qu'on pourra encore jamais savoir. Si, si, tous les biais ont été enlevés. Après quoi, comme on l'a dit, le fait déjà d'être peut être peut être plusieurs à avoir un regard différent, à avoir réfléchi à la question. Rien que le fait d'en avoir conscience de départ et d'essayer d'enlever des biais, c'est déjà pas mal. Faut en avoir conscience. Après tout, tous les biais et on n'y arrivera pas. Il y a un autre indicateur qui nous permet infiner de savoir si les données étaient suffisamment bien traitées au départ. C'est le résultat final. Donc comme nous, comme vous l'a montré Caroline tout à l'heure avec l' exemple du cv, c'est à dire a posteriori, une fois que le modèle est créé, de regarder sur quoi est ce qu'il se base pour prendre sa décision. Et dans ce cas on voit si les critères sur lesquels ils se basent sont biaisés ou non. Et donc là on saura si le jeu de donné était biaisé au départ ou non, ou en tout cas si ces biais ont influencé la décision. Parce qu'au final c'est quand même tout ce qui compte.
On peut rationaliser un minimum son jeu d'entraînement en cherchant des sous populations, en regardant un peu comment se constituer le jeu de données, mais ensuite c’est surtout, l'applicabilité, interprétabilité de comment fonctionnent l’algorithme qui nous permet de s'assurer qu’au moins le résultat sera sera pas biaisé.
WendyUne question maintenant, au vu de la minute qui nous reste, je vais prendre la question qui a eu le plus de like ? C'est celle de Manon. Avez vous une idée sur le pourcentage d'entreprises qui utilisent une IA pour une présélection de cv ?
Caroline Aucune idée.
Très bien passé.
CarolineDésolée.
WendyEt si un des problèmes est la proportion des hommes dans les données de départ peut-on entraîner 2 IA. : une spécifique pour les hommes et une spécifique pour les femmes ?
Il vaut mieux dégenrer les cv. Puisque ça permet de vraiment faire ressortir les points importants du cv. Et donc du coup, vaut mieux dégenrer tout ce qui peut porter à risque dès le départ, plutôt que de commencer à scinder les jeux de données. Ensuite, il faut trouver une IA pour les gens provenant des écoles d'ingénieurs, une IA pour les gens provenant des universités de n'importe où comme ici. On commence à scinder par les biais sociétaux sans jamais en finir. Il vaut mieux traiter les données globalement pour une meilleure performance de l'IA.
AméliePour moi, au-delà de ça. Avec cette cette idée là, on est dans un niveau supplémentaire de biais parce que finalement, c'est plus le modèle qui est biaisé, c'est la démarche. Parce que, en fait, on est en train de créer un traitement spécifique pour les hommes et un traitement spécifique pour les femmes. Et donc, déjà au départ, on est en train d'adopter une démarche qui est biaisée. Donc pour moi, ça ne résout pas le problème. Et même pire, il y a un problème dans le concept.
Merci à toutes les deux. On a un petit peu dépassé le temps. Je tenais à vous remercier à tous pour votre participation et pour vos nombreuses questions. Merci à vous deux également Caroline et Amélie pour avoir partagé tout cela avec nous aujourd'hui. Et puis la conférence a bien été enregistrée et elle sera accessible sur la chaîne YouTube de Sopra Steria dans les jours à venir. Donc une nouvelle fois merci à tous. Et puis on espère très vite.
AmélieMerci à tous. Merci.
Replay Webinar : Business Analyst, le médiateur entre le métier et la technique
Orateur 1 - Nora Hubert, Business. Analyste au sein de la société Sopra SteriaBonjour à toutes et à tous. Je suis très contente d'être là aujourd'hui pour vous présenter le métier de business analyst avec mon collègue Raphaël. Je pense que c'est une profession qui mérite d'être connue et donc nous voilà aujourd'hui pour vous parler de ce métier là. Je vais commencer par me présenter. Hubert, je suis business. Analyste au sein de la société Sopra Steria dans l' Agence de Normandie. J'ai fait des études en management et en gestion de projet dans des écoles de commerce et ensuite j'ai fait du recrutement et c'est en recrutant que j'ai découvert les business analyst. Et là, je me suis dit franchement, c'est ça que je voulais faire. Donc je me suis lancé dans cette aventure-là. Et ça fait deux ans que je suis chez Sopra Steria en tant que business analyst. Depuis peu, je suis passée directrice fonctionnelle de mon pôle pour aider tous les business analysés de mon pôle. Voilà, et je vais maintenant laisser Raphaël se présenter à son tour.
Je ne savais pas que ça existait avant de le découvrir. Ça s'appelle la police des publicités. Donc j'ai réalisé les contrôles avec des feuilles de papier, des dossiers papier. Se rendaient au bord de la départementale et ils ont inspecté le panneau Carrefour qui faisait sa pub pour son pour sa viande à moins 50 %. Et il se posait la question est ce que ce panneau est réglementaire par rapport à la loi ? Et y prendre des notes au pied du panneau, au bord de la route. Ils faisaient des retranscriptions sous Word et sous leur outils quand il rentrait au bureau. Ensuite, ils créent les PV de leur côté. S'ils avaient besoin d'émettre des PV, c'était assez archaïque, C'était assez compliqué et ils ont eu le besoin de changer. Ils ont eu le besoin de pouvoir se moderniser et d'être plus efficaces pour être plus efficaces, du moins ce qu'on a fait avec eux, je vous les résume. Là, on a réalisé des ateliers avec des agents territoriaux pour comprendre leur travail. Ça, c'est le métier du business analyst et de comprendre comment ils fonctionnent, quel est leur travail.
Orateur 2 - Raphaël, business analyst chez Sopra SteriaOn les met dans leurs baskets. J'ai eu l'occasion d'aller sur le terrain avec eux, donc voir concrètement comment ils faisaient. On a ensuite rédigé, une fois qu'on avait pu voir comment ils travaillaient, la rédiger, les grandes fonctionnalités dont ils avaient besoin. Quelles étaient les grandes règles métier auxquelles ils répondaient ? Il y avait des contraintes légales. Il y avait des modes de fonctionnement inhérents à leur secteur public. Il y a pas mal de choses comme ça qu'il fallait prendre en compte. Donc on a listé toutes ces règles là. C'est la partie rédaction qu'on a vu avant. On a également fait des maquettes pour vous les projeter sur ce qu'on pouvait leur proposer et ensuite on est passé à la phase de développement. Et c'est là que le rôle de Béa est très intéressant également. On a suivi tout le travail des développeurs pour bien bien comprendre, bien, voire s'assurer que leur travail allait répondre aux besoins de Catherine. Catherine qui était inspectrice et qui était au pied des panneaux sur la route. Et donc Catherine, elle avait besoin d'une application et besoin de fonctionnalités et on s'assure au fur et à mesure du projet que ce qu'on est en train de faire, ça fonctionne.
Replay Webinar : L’agilité, plus qu’une méthode, un état d’esprit
Replay Webinar : Les nouvelles technologies du développeur – Kafka & Azure
Replay Webinar : IA & confiance, quels enjeux ?
Tout simplement parce qu'en fait la confiance dans le système n'est pas suffisante. Il y a quelques erreurs et ils considèrent que c'est pas comme il faut et donc en fait le système n'est pas utilisé. Donc oui, la confiance est absolument nécessaire pour que le système soit utilisé. Et en particulier, elle s'exprime de façon assez forte dans ce troisième été de l'intelligence artificielle sur les sujets d'apprentissage automatique. Donc on a décidé de concentrer notre notre propos aujourd'hui sur cette technologie. On l'utilise partout. Comment ça peut se manifester en fait cette confiance quand, pour un service bancaire, je dois accorder un crédit ? J'ai envie de savoir si la raison pour laquelle le crédit sera apporté ou ne sera pas apporté pour pouvoir effectivement l'accorder. Au niveau des services publics. J'ai envie qu'en fait je sois traité correctement et indépendamment de mon ethnie, de mon sexe, de ma religion, etc. Et donc il faut que j'ai confiance dans les hommes, dans les systèmes qui supporteront mes demandes.
Ils sont portés par des dimensions techniques qui relèvent à la fois de la partie algorithmique à partir des données, et ce, à la fois au moment de la construction du système mais aussi lors de son utilisation. Donc, on a choisi de faire un focus sur ces sujets, vraiment les sujets techniques de la confiance et c'est Michel qui va nous en faire le descriptif.
Tous les data scientists adoraient le garder à l'esprit. Parce que c'est vrai, tous les modèles sont faux et sont donc biaisés parce qu'ils cherchent à représenter. Une réalité est qu'en tant qu'humain, on ne connaît pas et qu'on ne connaîtra jamais et peut être d'avoir une relation privilégiée avec des divinités. Mais sinon on en gardera une perception humaine. Donc par conséquent, autant c'est facile de faire des faux modèles et je sais que j'y arrive assez bien et je ne pense pas être le seul. Autant ça peut s'avérer difficile de trouver des modèles d'IA utiles et la validation de l'utilité des modèles est donc capitale. Et les critères de validation de cette utilité sont typiquement des critères de performance quand on connaît bien les data scientist . Par exemple, pour la classification, il y a la précision, le rappel, le score. Enfin il y a la régression, il y a les moyennes quadratiques. En fait, il existe une multitude d' indicateurs de performance et il est très important de bien choisir afin de choisir les bons.
Et il est aussi même important de définir les bons objectifs de performance, car la difficulté de développer une IA croît exponentiellement avec ce niveau de performance. Mais c'est un autre débat. Un autre problème bien connu des data scientists qui ramènent au postulat précédent c'est le fameux dilemme entre biais et variance, pour lequel il faut trouver un compromis qui revient généralement à choisir un autre modèle biaisé mais plus complexe et plus instable, et un modèle plus biaisé mais plus stable. Un modèle peut être très bon du point de vue des critères de performance que je viens de dénoncer. Sans être par exemple sûr et équitable, il peut aussi ne pas être robuste et stable. Et on ne peut pas accorder de la confiance à une IA pour laquelle les critères de fiabilité n'ont pas été vérifiés.
Et il existe différents niveaux. Il n'y a pas de consensus dans la définition de ces niveaux. Moi, je vais vous proposer ici une définition qui n'est pas la mienne. Elle est largement admise et elle a le mérite de faire une distinction claire entre expliqué, habilitée et interprète habilitée. Or, selon cette définition.
Relations de cause à effet, alors qu'avec les techniques d'explications habilitées, l'on cherche à comprendre ses relations. Et pour cela on est obligé, on est obligé d'ouvrir la boîte noire. En tout cas, grâce à cette définition, on peut dire que toutes les réalités sont plus ou moins interprétables et sont-elles applicables ? Or, ce n'est pas sûr et rien ne l'atteste. Et moi, personnellement, je pense que toutes les réalités ne sont pas explicables, y compris pour des réalités de notre quotidien. De plus, il est souvent nécessaire de biaiser la réalité pour la rendre explicable, voire même simplement interprétable. Or, ce problème soulève une question fondamentale. Est ce qu'il vaut mieux utiliser un modèle explicable mais biaisé et moins performant qu'un modèle non explicable, mais nettement plus performant et dont cette performance a pu être validé empiriquement ? Il faut savoir que pour l'instant, dans de nombreux domaines, dans l'aéronautique et les transports, la réglementation en vigueur oblige d'utiliser des algorithmes explicables. Et cette réglementation interdit donc d'utiliser.
En ce qui me concerne, je suis assez d'accord avec des personnes comme John McCain qui y prétendent que si on veut vraiment profiter pleinement des et de formidable capacité de l'Iran, il faudra admettre d'utiliser des modèles non explicables qu'on pourra néanmoins valider très rigoureusement de manière empirique. Ce qui nous emmène au flight suivant sur la validation. Alors qu'est ce qu'on entend par validation empirique par rapport à une validation logique ? La validation empirique ou pseudo empirique s'appuie que sur l'expérience et sur l'observation.
Ce qu'il convient absolument de faire pour ne pas s'exposer à des risques de dérives qui pourraient être très préjudiciables, il est aussi absolument nécessaire de s'assurer qu'il y ait malgré tout ou pas de telles dérives. Pour cela, il faut définir dès les premières étapes du cycle de vie du vol et les procédures de contrôle et de mise à jour de cette IA via une boucle retour. Or, c'est vrai pour tout.
Tous les gars de Machine Learning. Mais c'est encore plus vrai et important pour des gens qui ont des capacités que je qualifierais d'autodestruction, comme les IA de détection de fraude. En effet, les saisies sont performantes. On peut supposer que les fraudeurs vont changer leur comportement et qu'ils vont rendre cette IA beaucoup moins performante.
François Marie LesaffreOn peut espérer interpréter plus ou moins tous les modèles d'IA. Est ce que c'est suffisant pour avoir confiance dans ces modèles ? Mais ça a été dit, il faut voir avec les autorités de régulation ou autre.Une question sur le démarrage d'Augustin, sur le démarrage avec l'IA en industrie. Quels sont les préalables pour démarrer sereinement avec l'IA en industrie ? En fait, ce n'est pas d'ailleurs propre à l'industrie et on peut dire que l'application clé en fait de l'IA, elle est sur les processus récurrents de façon à ce qu'on appelle l'excellence opérationnelle. Et c'est là où on peut voir dans les entreprises et notamment dans l'industrie, les enjeux clés d'usage et les gains les plus importants qu'on peut qu'on peut en attendre. Alors pour ce faire, qu'est ce qu'il faut en fait ? Il y a trois étapes de maturation parce qu'on cherche à optimiser les process et pour optimiser un process, il faut déjà le maîtriser. Et pour le maîtriser, il faut le mesurer. Ça tombe bien parce que la mesure, ça produit des données. Et pour faire des systèmes à base d'intelligence artificielle, il faut des données et des connaissances. Donc. Le préalable pour démarrer sereinement, c'est que vous ayez un processus qui soit déjà maîtrisé.Pour dire qu'effectivement il faut un processus. Il faut donc ce processus là aussi ce sont les métiers qu'il maîtrise et il faut absolument une adhésion des métiers à alias. Alors souvent il faut démystifier un peu. Lia pas moi, j'ai pu m'en rendre compte chez vous, j'ai pas mal de clients où il y a une peur par rapport à l'IA et où les métiers sont assez frileux pour collaborer. Il peut y avoir aussi des craintes assez légitimes, légitimes, qui peuvent leur paraître légitimes. Mais justement, il faut leur expliquer.
Merci beaucoup pour votre participation et vos questions. C'est très stimulant parce que quand on vous voit pas, on a quand même une interaction avec vous. On a pris beaucoup de plaisir, je pense à échanger avec vous et désolé pour ne pas avoir terminé, on va s'arrêter là. Et puis un grand merci de votre part et puis une excellente journée.
Michel PoujolMerci à vous et bonne journée à tout le monde.
Replay Webinar : Lead Développeur, un métier d’avenir
Replay Webinar : la chaîne DevOps de Sopra Steria
Benjamin Chossat, architecte au sein du groupe Sopra Steria
Replay Webinar : quel avenir des métiers de la data ?
Replay Webinar : l'UX Design, l'autre volet de l'agilité