C'est le moment où c'est stressant. Alors on va commencer, même s'il reste encore un peu de place et qu'il y avait normalement 99 personnes sur le meet-up. Je pense qu'il y a des gens qui vont arriver au compte-gouttes, mais on va y aller juste la zappette. Non. Merci à tous d'être là, merci à tous d'être venus. Donc bienvenue chez Comet, Charles va vous présenter Comet juste après. Moi l'idée c'est que je vous fasse une petite intro sur ce qu'est French Produit. C'est une asso qui s'appelait avant SPCX, LPCX, qui est maintenant French Produit. Je pense que la plupart dans cette salle connaissent un peu l'association. C'est une association qui fédère une communauté sur toute la France, donc il y a un Slack, des chapters pour organiser des événements, dont celui-ci à Paris. Ensuite, 8 chapters régionaux pour organiser tous les événements au sein de la France. Je ne vais pas faire la liste, mais vous voyez un peu qu'on est justement l'asso réparti dans toute la France. Il y a un Slack, je le disais, donc c'est un bon test pour ceux qui ne sont pas sur le Slack, vous pouvez scanner le QR code pour vous inscrire. Je regarde s'il y en a qui lèvent le téléphone, un petit peu. Je vous laisse prendre en photo. 2 300 Product People dans le Slack, 4 000 sur Meetup parce qu'il y a un filtre à l'entrée du Slack, on a le droit de voter oui ou non si vous avez le droit d'entrer. Il faut être évidemment Product Manager et qu'est-ce que c'est justement nos valeurs-cœur ? C'est gratuit pour tous, tout ce qu'on fait, donc les Meetup, vous n'avez pas payé, heureusement. C'est entre pairs, évidemment, comme je le disais, on est entre Product Manager et puis évidemment aussi sans prosélytisme. C'est-à-dire que vu que c'est filtré, il n'y a pas de vente. Voilà, donc même ceux qui créent des produits comme Scribd ne vont pas vous vendre ça sur Slack, évidemment. Des produits pour les Product, mais voilà. Pourquoi c'est gratuit ? Parce qu'il y a des gens derrière, beaucoup de gens. Une équipe de bénévoles, là c'est évidemment l'équipe de French Produce Paris avec Alexandre, Anne, Xavier, Céleste, Anthony et Étienne, moi-même. Anthony, pas Étienne. Donc des bénévoles. Et puis aussi trois sponsors. Abizori, un cabinet de consulting en product. Sendinblue, une plateforme marketing tout en un, donc pour vos campagnes Facebook Ads et vos campagnes aussi SMS, e-mail. Et puis Exalt, aussi un cabinet de consulting product. Et donc tous ces trois sponsors nous aident évidemment à financer ces événements et tout ce qu'on organise aussi en virtuel sur Slack. Et puis évidemment à chaque meetup, il y a un host et ce soir, c'est Comet. Donc ce lieu, je laisse Charles vous présenter Comet. Bonsoir à tous. Merci d'être ici. Ici c'est Comet. Ici c'est Paris, mais ici c'est Comet. Donc c'est quoi ? Comet c'est huit lieux dans trois pays et surtout 170 personnes qui sont au service de la réussite de vos réunions. Donc vous êtes là ce soir. Demain, à votre place, il y aura des gens d'une entreprise qui vont venir toute la journée pour avoir une belle réunion en dehors de leurs locaux. Et ils vont trouver donc ce lieu assez unique et assez chouette. Et chaque lieu Comet a sa touche personnelle. Donc ils vont trouver les lieux, ils vont trouver tous les services associés. Donc la restauration, quelqu'un comme Alex qui est ici avec nous à la technique et qui leur permettra d'avoir vraiment quelque chose sans couture. Et puis un accueil aux petits oignons. Donc tout ça pour un prix par personne tout inclus et compétitif. Donc ça c'était la partie pub de ce qu'on fait. On est globalement des gens qui n'aimons pas tant que ça les réunions. Ce qu'on pense c'est qu'il faut se réunir moins mais mieux. Donc quand on a des réunions, vraiment les mettre dans un écran et avec le service qui permettent d'en tirer le meilleur parti. Et on a aussi une conviction, c'est que le travail hybride est là pour durer. Merci le Covid là-dessus. Et on a justement la volonté, on a commencé à développer une offre où en plus de ces moments courts qui sont les réunions, on a maintenant une offre pour les moments plus longs qui vont être des locations de bureau, une sorte de co-working si vous voulez. Mais vraiment adapté aux entreprises hybrides et donc très concrètement des co-working, des bureaux flexibles où vous aurez la place, vous aurez des salles de réunion disponibles. Ce qui est souvent le gros problème sur les espaces de bureaux traditionnels qui ont été conçus avec beaucoup beaucoup de bureaux et peu de salles de réunion. Donc nous on a, on pense que le monde a évolué. Puis quand on vient au bureau c'est pas juste pour faire sa spec, travailler tout seul dans son coin, c'est pour être avec des gens, pour socialiser. Et donc on a des nouveaux types d'espaces pour vraiment s'adapter à cette nouvelle réalité. Donc le future of work est maintenant. Donc voilà pour Comet, une anecdote sur moi comment j'ai découvert Comet. Et bien c'était ici même et c'était exactement dans cette configuration. J'étais à votre place dans le public, il y avait un meetup french produit organisé. Et puis quelqu'un qui a présenté Comet qui était Anthony. Et à la fin de son speech il a dit au fait on recrute un head of product. Donc là j'ai eu des étoiles dans les yeux. Donc figurez-vous qu'on recrute toujours, on recrute un product designer et Anto a dit qu'il n'y avait que des product managers dans French Produit. C'est faux, il y a tous les profils produits incluant des product designers. Donc s'il y en a dans la salle et qui sont intéressés, vous pouvez évidemment nous contacter. On est là pour vous. Donc voilà, merci encore d'être là et puis on va passer au vif du sujet maintenant. La conf. Bonsoir à toutes et tous. Déjà merci à French Produit de m'avoir invitée ce soir. Puis merci à vous toutes et vous tous d'être venus en ce mercredi soir. On salue aussi les gens qui sont là sur YouTube. Je voulais commencer par un sondage. Qui d'entre vous travaille sur un produit de type B2B SaaS ? Si vous pouvez lever la main. Il y a moins que ce que je pensais, ça se lève petit à petit. Je pense qu'on a bien 80 % de l'audience sur du B2B SaaS maintenant. Thibaut, je t'ai vu lever la main, tu vas pouvoir relever la main. Qui travaille sur un produit avec de l'intelligence artificielle ? On a une dizaine de personnes, pas mal. Pour ceux qui n'ont pas du tout levé la main, est-ce que vous voulez bien lever la main à l'inverse ? J'aimerais savoir sur quel type de produit vous travaillez. Est-ce que par exemple tu peux nous dire sur quoi tu travailles ? Ok, Web3, je répète pour ceux qui n'ont pas entendu, Web3 NFT. Si je résume, si on essaie de catégoriser. Est-ce qu'il y a une autre personne qui veut me dire sur quoi elle bosse ? Qui n'est pas dans l'IA, ouais. SNCF Connect, ok. Donc plutôt B2C, du coup, clair. Pourquoi je vous pose ces questions ? Parce que je suis persuadée que dans cette répartition, on a vu qu'on a une très grande majorité de l'audience qui travaille sur du B2B SaaS, beaucoup moins sur l'IA, et puis sur d'autres typologies de produits. Je pense qu'on reprend la même audience dans 5 ans, et on n'aura pas du tout cette répartition. Je pense qu'à la même question, je pense qu'on aura beaucoup plus de mains sur l'IA, et puis peut-être un peu moins sur le B2B SaaS, et beaucoup plus de typologies de produits. Ça va être ça un peu la discussion qu'on va avoir ce soir. Parce qu'une des questions que je me suis posée, c'est, ok, c'est quoi la schize la plus importante pour un PM ? Pour un PM qui, dans sa carrière, va être amené à travailler sur différentes typologies de produits. Et donc il va devoir, il va être confronté dans sa carrière à des produits pour lesquels les méthodes by the book, elles ne vont pas fonctionner. Je vous ai remis les skills, parce que pour moi, il y a un triptyque. Il y a un bon PM, on dit toujours, il faut qu'il ait de l'empathie. Oui, évidemment, il faut qu'il ait de l'empathie pour son utilisateur. Il faut qu'il ait du leadership et des bonnes capacités de communication pour emmener son équipe, ok. Ça, je pense qu'on sera tous d'accord. Maintenant, ça fait sauter mes icônes, les changements de police. S'il y a vraiment une capacité à se poser des questions. Pour moi, c'est ça la schize que vous devez emmener avec vous dans votre carrière, parce qu'en fait, vous allez être confronté à ces produits, ces produits atypiques qui rentrent pas dans le cadre, et c'est ça que vous allez pouvoir réutiliser. Et c'est de ça dont on va discuter ce soir. Alors, qui suit ?
Je suis Emmanuelle, je suis ingénieure de formation. J'ai une quinzaine d'années d'expérience et ça fait 10 ans que je fais du produit. Aujourd'hui, depuis le début de l'année, je suis CPO en freelance, c'est-à-dire que j'accompagne des start-up qui veulent structurer leur fonction produit. Et auparavant, j'ai travaillé dans différentes start-up. J'ai travaillé chez Netatmo, qui fait des objets connectés dans la maison. Je vous ai mis un visuel. Vous voyez, elle fait des stations météo connectées, caméras de sécurité connectées, thermostat connecté. J'ai vécu l'aventure du skate chez Netatmo. Je suis arrivée quand c'était une trentaine de personnes, jusqu'à ce que ce soit plus de 200 personnes. J'ai monté une partie de l'équipe produit là-bas. Et faire des objets connectés, qu'est-ce que ça veut dire ? Ça veut dire mettre en musique une équipe avec plein de métiers différents. Des ingénieurs en électronique, en mécanique, en software embarqué, application mobile, back-end, front-end. Finalement, c'est assez compliqué. Mais à la fin, il faut que ce soit très simple pour l'utilisateur, parce que c'est un produit grand public. Il faut que son expérience, elle soit sans couture. Une fois que je vous ai dit tout ça, c'est quoi le challenge pour un PM ? C'est qu'il y a une composante hardware, et donc c'est pas un produit qui rentre vraiment dans le manifesto agile. Plus récemment, j'étais en charge du produit chez Mindy. Mindy, c'est une start-up qui fait des API de document processing. Alors, qu'est-ce que ça veut dire, le document processing ? Je vous ai mis un exemple ici. En fait, c'est qu'à partir de factures, sur une facture, on va utiliser des algorithmes d'intelligence artificielle pour aller extraire les informations clés dans cette facture. On va être capable d'extraire le montant total de la facture, la date de la facture, le fournisseur, et ça automatiquement. C'est-à-dire qu'une facture qui est envoyée à l'API de Mindy, on va pouvoir récupérer de façon structurée des informations sur cette facture. Ça sert à quoi ? Ça sert aux développeurs et aux product managers qui veulent éviter que leurs users viennent ressaisir ces informations manuellement, ce qui est source d'erreur, source de friction, que ça soit complètement automatisé dans leurs applicatifs. Et donc pour faire tout ça, il y a une très forte couche d'intelligence artificielle. On va en parler plus en détail juste après. Et pourquoi je vous parle de tout ça ? Parce que vous voyez, je vous ai montré Netatmo, je vous ai montré Mindy, c'est aussi ce qui caractérise mon parcours en produit, c'est que je n'ai jamais travaillé sur des produits pour lesquels la méthode au by-the-book, elle fonctionnait. Donc ça a nécessité qu'à chaque fois, je reparte un peu from scratch, à me dire, OK, quelle est la méthode que je peux construire qui va fonctionner sur le produit sur lequel je travaille ? Vraiment, c'était pas ça mes icônes, je vous le dis. Rires Ce que j'aime bien, c'est qu'il y a une petite touche de couleur, c'est sympathique. Donc dans cette présentation, il va y avoir deux parties. La première, c'est que je vais vous faire un retour d'expérience dans l'IA. Quelle est la méthode qu'on a mise en place chez Mindy, qu'on a développée et qui a fonctionné et vraiment adaptée à notre produit à ce moment-là ? Et dans une deuxième partie, un peu par provocation, je vous ai appelé ça la non-méthode, parce que je sais que nous, les produits, on en a marre des méthodes. Il y en a plein, il y en a tous les jours des nouvelles. Donc là, c'est un peu une non-méthode, c'est plutôt une boîte à outils que je vais vous proposer. Si demain, vous prenez un nouveau job sur un produit qui ne rentre pas dans le cadre, vous aurez quelques tips que vous pourrez utiliser. Alors, dans ce retour d'expérience dans l'IA, la première chose que je voulais vous dire, c'est pourquoi, en fait, on a dû... Oui, moi aussi, ça me faisait... J'essaie de plus les regarder, je ne les regarde plus. Je ne les regarde plus. Donc pourquoi... Non, mais c'est vrai, il faut que je les regarde, t'as raison. Pourquoi dans l'IA, on a besoin de créer sa propre méthode produit ? Vous allez me dire, pourquoi réinventer la roue, finalement ? Parce qu'en fait, c'est assez spécifique comme métier. Développer des modèles de machine learning, de deep learning, et ça, je vais vous expliquer un peu plus après, mais dans les grandes lignes, c'est que ça met beaucoup de temps. Il y a un temps de développement qui est hyper long. Donc du coup, vu que c'est très long, c'est quand même difficile d'appliquer la méthode agile. Ça n'a pas de sens de faire des sprints de deux semaines là où on a plusieurs semaines, voire plusieurs mois pour aboutir à quelque chose. Donc c'est vrai que le découpage en MVP aussi n'est pas simple. Et le dernier point, je pense que ça, c'est aussi assez atypique et assez singulier quand on fait de l'intelligence artificielle, c'est qu'on peut échouer. C'est-à-dire qu'on peut se dire, voilà le modèle, voilà ce qu'on aimerait qu'il fasse, mais ça se trouve, à la fin, on va passer des mois à essayer de développer quelque chose qui ne marchera pas. Parce que l'approche qu'on aura prise, elle ne fonctionnera pas. Parce que les performances de notre modèle ne seront pas suffisantes pour le déployer et le proposer à l'utilisateur. Ça, je pense que c'est vraiment unique. Je vous ai fait un petit rappel, une petite explication très jolie avec des petits chats et des petits chiens, sur qu'est-ce que c'est qu'un modèle d'intelligence artificielle. Typiquement, là ce qu'on veut, c'est un modèle qui va être capable de prédire quand il voit une image de chat ou de chien, si c'est un chat ou si c'est un chien. Mon modèle, pour qu'il soit capable de prédire si ce mignon petit chat, c'est bien un chat, il va devoir apprendre. Pour ça, je vais devoir lui donner des images en disant, ça, tu vois, ça c'est un chien, mais ça c'est un chat. Donc on lui donne des données qui sont annotées. Donc il a l'image et puis il a la vérité à côté. Avec tout ça, il va apprendre. Il a besoin d'un certain volume de données pour être capable d'apprendre. Une fois que mon modèle il est entraîné, je vais vouloir voir est-ce que mon modèle il est performant. Donc je vais lui envoyer des données, je vais regarder, je vais regarder ce qu'il me prédit. Là, je vais vouloir l'évaluer, je vais vouloir évaluer ses performances, à quel point il a raison, ou à quel point il se trompe. Si je suis pas contente des performances du modèle, je reviens là. Je me dis, en fait, peut-être que j'ai besoin de plus de données, peut-être qu'il faut que je retravaille sur mon modèle. Une fois que je vous ai dit tout ça, vous comprenez pourquoi ça prend du temps. Je vous ai reprojeté ça sur une échelle de temps, c'est que toutes ces étapes, depuis cette phase d'annotation des données, où je crée toutes les données dont mon modèle va avoir besoin pour s'entraîner, et le moment où je travaille sur mon modèle, je l'évalue et je refais toute cette boucle, au départ, chez Mindy, ce qu'on avait constaté, c'est qu'en moyenne, il nous fallait 6 mois pour travailler sur une itération. Et on avait envie de réduire ce temps de développement. C'est ce qui nous a poussés à réfléchir sur comment on peut améliorer ça, comment on peut accélérer nos déliveries. Accélérer nos déliveries, ça nous permettait aussi de nous challenger en disant, si on accélère, ça va nous permettre potentiellement aussi de dérisquer, parce qu'en fait, ça va nous pousser à découper, à découper nos projets en différents scopes. Une fois que je dis ça, ça semble logique, découper en scopes, mais comment on fait concrètement quand on parle de modèles et quand on parle d'intelligence artificielle ? En fait, ce qu'on s'est dit, c'est qu'en fait, ce qu'il faut qu'on comprenne, c'est à quoi l'algo... Je vais parler de modèle ou d'algo, c'est synonyme, mais l'algo, ça va plus vite. C'est que, qu'est-ce qui doit supporter notre algorithme ? À quoi s'attendent nos utilisateurs ? Et à quoi il va être confronté dans la vraie vie, c'est-à-dire en production ? Ça va être quoi les cas qu'il va avoir passés et qu'on doit être capable de supporter ou non ? Et donc, pour faire tout ça, en fait, la première étape, le truc le plus important, c'est de dire, il faut qu'on comprenne cette donnée, il faut qu'on comprenne la réalité de nos algos en production. Ça nous a donné... En fait, on a développé notre propre méthode. Alors, il y a trois étapes, et je vais revenir sur chacune d'entre elles. Dans cette partie 1, je vous présente comment on a déroulé cette méthode, et puis dans la partie 2, je vous expliquerai comment on est arrivés à tout ça. Donc, on s'est dit, il faut qu'on explore la donnée au départ, c'est-à-dire qu'il faut qu'on comprenne vraiment quelles sont les différentes configurations auxquelles notre algo va être soumis. En plus, ça va nous permettre de découper en type MVP. Alors, je vous ai mis MVP entre côtes, parce que ça ne va pas être le MVP un peu classique, mais c'est vraiment d'avoir une approche où on essaye un maximum de découper. Et puis, ça va nous permettre de prendre des décisions orientées sur la donnée, c'est-à-dire que cette approche d'exploration va nous permettre d'avoir vraiment de la stat pour être vraiment... à prendre des décisions de façon très rationnelle et très pragmatique. Alors, c'est quoi, la data exploration ? Je vous ai remis une définition, mais l'idée, c'est de dire, je prends un ensemble de documents de départ, enfin, de données de départ, il faut définir la taille. On est d'accord que si on regarde 10 documents versus 400, ça ne va pas avoir la même représentativité. Donc, il faut définir au départ quel est le volume de données qu'il est nécessaire de regarder pour avoir une représentativité. Et en fait, de toutes ces données que je vais regarder, ça va me permettre de voir quels sont les patterns qui reviennent, quels sont les outliers. Et c'est exactement ce qu'on a mis en place. Je vais vous parler d'un projet pilote sur lequel on a appliqué cette méthodologie que je suis en train de vous décrire. Chez Miley, on a travaillé sur extraire les lignes dans les factures. Je vous ai montré les factures au tout début. En fait, ce qu'on voulait faire, là, vous voyez cette facture, il y a un tableau dedans. J'ai un tableau et puis j'ai différentes lignes qui présentent différents services dans mon tableau. Et ce qu'on voulait extraire, c'était ces lignes à l'intérieur. Donc, vous voyez, là, on voit un beau tableau, c'est super. Celle-là, elle est magnifique. On voit un beau tableau, j'ai des belles colonnes, j'ai quatre colonnes, j'ai trois lignes. Et donc, en fait, ce qu'on voulait extraire, c'est être capable d'envoyer automatiquement à l'utilisateur, c'est-à-dire, en fait, dans la ligne 1, j'ai telle description, j'ai telle quantité, j'ai tel prix, j'ai tel montant, etc. sur les trois lignes. Et donc, j'y arrive pas avec ces icônes, je suis très triste. Et donc, l'idée, c'était que comment on arrive à trouver... Enfin, quel est le volume de données qui va être nécessaire pour nous pour que ça soit suffisamment représentatif ? Et donc, ça, j'ai travaillé avec l'équipe Data Science, on s'est dit, voilà, il nous faut 400 données. Donc, qu'est-ce que j'ai fait ? J'ai pris 400 factures et puis je les ai regardées. Je les ai pas regardées qu'une fois, je les ai regardées quoi ? Six, sept fois. Pour essayer de comprendre, en fait, c'est quoi les patterns ? Qu'est-ce qui revient ? Où est-ce que l'algo va peut-être galérer ? Qu'est-ce qu'attend le user, en fait ? C'est ça qu'il faut comprendre.
On essaye aussi de comprendre, là c'est facile, avec mon œil humain je le vois bien le tableau, je comprends bien ce qu'il faut extraire. Mais il y a des configurations qui ne sont pas si simples. Je vais vous montrer quelques exemples. Ça c'est ce que j'ai mis, ça c'est un cas simple. J'ai un beau tableau toujours, un beau header avec mes colonnes, mes intitulés de colonnes, mes lignes. Mais là je vous ai mis des exemples un peu moins sympas. Typiquement là, j'ai un item qui est sur deux lignes. Je le sais parce que j'ai passé du temps à lire le tableau, mais quand je le regarde, chaque ligne a été tracée. Qu'est-ce qu'on veut supporter en fait ? On s'attend à quoi pour la loi ? Ça c'est un exemple. Autre exemple ici, ça c'est un autre tableau. La dernière ligne c'est quoi ? La dernière ligne, elle respecte pas le pattern des différentes colonnes. Tout a été, c'est comme si c'était une seule ligne. L'utilisateur il s'attend à quoi ? En fait c'est ça la question d'un point de vue produit qu'on doit se poser quand on fait cette exploration. Il y a ce que l'algorithme va réussir à faire, mais aussi le user, est-ce qu'il va être frustré si on n'y arrive pas, si on sort quelque chose qui n'est pas correct, ou est-ce qu'il va se dire, même moi en tant qu'humain des fois je suis pas trop sûr. Et le dernier exemple là, c'est que j'ai pas de colonne en fait. Enfin j'ai des colonnes pardon, mais j'ai pas d'intitulé de colonne. Qu'est-ce qu'on veut supporter ? Donc c'est ça l'objectif de cette phase là, c'est d'aller dans ce détail en profondeur de la donnée pour comprendre les configurations qui vont être les plus récurrentes et de savoir comment on veut les supporter. Donc ça, ça a été la base pour nous pour définir notre spécification. Je vous ai mis l'exemple un peu à un extrait de notre spec ici, c'est que pour chacun des cas qu'on avait identifiés, on a essayé de définir OK, c'est quoi l'occurrence ? Est-ce que ça arrive souvent ou non ? Et c'est quoi notre priorité à résoudre ce problème ? Et à partir de là, ça donne une idée claire à l'équipe de Data Science sur quoi elle doit mettre son effort. Parce qu'en fait, les modèles sont toujours améliorables. Donc on peut passer beaucoup de temps à vouloir résoudre tous les problèmes en même temps et ça, ça nous a permis d'avoir beaucoup de focus et choisir sur quels problèmes on veut mettre de l'effort. Je vous disais en intro, ça nous a permis de prendre aussi beaucoup de décisions très orientées sur les statistiques. Je vais prendre un exemple. On s'est posé la question au départ, OK, un tableau dans une facture en moyenne, il a combien de lignes ? Combien de lignes on doit être capable de supporter ? On savait qu'on allait avoir une contrainte parce qu'on avait des contraintes de temps de calcul, et on avait envie de comprendre très tôt, OK, dans la vraie vie, qu'est-ce qu'on va rencontrer comme type de document ? Donc dans la phase de spec, j'ai re-regardé mes 400 factures, et j'ai regardé combien il y avait de lignes sur chacun des documents quand il y avait un tableau. Ça m'a permis d'avoir ce petit camembert là, et en fait on voit que deuxièmement, là il y a pas de tableau, là il y a une seule ligne dans mon tableau, etc. Si je regarde, là j'arrive jusqu'à neuf, en fait j'ai 98 pour... Plus de 98% de mon dataset d'exploration qui contient moins de lignes. Donc ça sert à rien que dès le départ on se dise, il faut absolument supporter 50 lignes, parce que c'est pas la réalité. Donc ça, ça donne aussi une idée de façon complètement statistique qui permet de prendre des décisions rationnelles. Ça, ça a été un super outil, je vous ai mis qu'un exemple, mais c'est quelque chose qui nous a servi à plusieurs reprises pour avoir une approche justement très mathématique. Si je résume un peu tout ça, c'est que je pense que dans cette approche-là, orientée très analyse de la donnée, ça a permis, je dirais, le plus important, c'est qu'on a fait le lien entre les algos, et la data science, et les attentes du user. En se posant à chaque fois sur, ok, cette configuration, est-ce qu'on a besoin de la craquer ou pas ? Parce que qu'est-ce que va penser le user si on répond ça, ou si on répond ça, ou si on se trompe ? Et donc ça ramène vraiment le côté penser à son utilisateur alors que tu fais des modèles de deep learning. Ensuite, ça nous a permis, vu qu'on a pu très tôt dire, en fait, c'est ça les problèmes les plus importants qu'on doit résoudre, c'est ça qu'on doit mettre en place pour pouvoir sortir le produit, et ces cas-là, si on les gère pas, c'est pas grave, on peut sortir quand même avec notre exemple de spec, avec nos priorités, nos occurrences. En fait, on a une boussole, ça donne une boussole aussi à l'équipe d'engineering de savoir où est-ce qu'elle doit mettre l'effort, et de ne pas essayer de tout résoudre en même temps. Donc ça, ça a été très, très efficace. Et je vous le disais, le côté data-driven, on prend de la stat, et ça, c'est hyper rationnel et c'est pas du ressenti. Donc c'est aussi un outil d'alignement pour se dire, en fait, c'est ça la bonne direction parce que ce sont les faits. Et ce qu'on a découvert, c'est que ça, on l'avait envisagé en face de spec, parce qu'on s'est dit, super, il faut qu'on ait ça dès le départ, et on avait imaginé justement cette méthode avec l'équipe Data Science. Ce qu'on n'avait pas anticipé, c'est que cet outil de data exploration, on allait aussi l'utiliser en phase de développement. Parce qu'en fait, les data scientists arrivaient et me disaient, ah mais Emmanuel, on a rencontré ce cas-là. Je disais, bon, attends, je vais regarder, est-ce que c'est un vrai cas ? Et donc je repartais, alors oui, c'est sûr, mes 400 données, je les connais par cœur. Mais au moins, je pouvais revenir, j'avais un outil qui me permettait de dire, OK, ça, peut-être qu'il faut qu'on travaille dessus, ou ça, non, en fait, c'est pas un sujet, laissez l'autre côté. Ça, on ne l'avait pas anticipé, et du coup, c'est un super outil qu'on peut aussi revenir utiliser dans toute la phase de développement. Alors, on avait cet objectif de dire, on veut réduire ce temps de délivrée. Je vous disais, au départ, on était aux alentours de 6 mois, on voulait être plutôt aux alentours de 4 mois, et ça, ça nous a permis tout ça. Donc on a pu réduire en essayant de réduire les scopes. Et je vous ai montré que quelques exemples, parce que déjà, je risque de déborder sur le temps, donc l'idée, c'était de vous donner un peu ce qui était le plus important, parce que je pense que le plus important à retenir de tout ça, c'est vraiment cette phase de data exploration. Si vous faites de l'IA demain, je vous recommande de passer du temps sur ça. Et si c'est un sujet qui vous intéresse, j'ai écrit un article sur le blog de Mindy qui détaille vraiment plus en profondeur, plein de choses qu'on a pu mettre en place, notamment dans l'aspect sur ces phases-là. Si ça vous intéresse, je l'ai mis dans les ressources qu'on pourra partager par la suite. Alors, là, je vous ai expliqué ce qu'on a mis en place. Évidemment, on n'est pas arrivés... Enfin, je ne suis pas arrivée... Moi, je n'avais jamais fait de l'IA avant d'aller chez Mindy, et donc on s'est posé avec l'équipe de Data Science, et on s'est dit, OK, on veut améliorer ça, comment on fait ? Donc on s'est posé ensemble. Et puis, de tout... Comment dire ? De cette partie méthode qu'on a développée et qu'on a mise en place dans l'IA, j'ai essayé d'en extraire un peu une théorie qui peut s'appliquer quand on travaille finalement sur des produits où on ne peut pas appliquer la méthode by the book. Comme je vous le disais en intro, l'idée, ce n'est pas que ce soit une autre méthode, une méthode de plus, mais c'est une non-méthode, c'est-à-dire que c'est une boîte à outils. Il y a quatre items, et c'est un peu des conseils sur si demain, vous prenez un job et que vous dites, je ne peux pas faire d'agilité, je ne peux pas faire du sprint, voilà quelques pistes. Et donc, je voulais vous dire, quand est-ce qu'on doit faire ça ? Vous avez montré, j'avais quatre critères dans l'IA. En fait, c'est un peu ces quatre critères qui me permettent d'évaluer, est-ce que je vais devoir aller creuser et aller potentiellement faire ma propre méthode ? Est-ce qu'on peut faire du MVP ? Si on ne peut pas faire du MVP, il va peut-être falloir passer du temps à se poser des questions, justement, et à aller imaginer une méthode ad hoc. Est-ce qu'on peut faire de l'Agile ? Est-ce que les temps de développement sont longs ? Et puis, j'ai mon dernier point qui est très lié à l'IA, mais est-ce qu'on a une incertitude d'aboutir ? Pour illustrer tout ça, je voulais vous montrer ce schéma qu'on a tous vu et revu, que je trouve génial, sur l'aspect MVP qui s'applique bien. C'est formidable de se dire qu'on part d'un skateboard et qu'on peut faire une trottinette et qu'on peut arriver à une voiture. Ce que je voulais vous dire, c'est que quand on fait, par exemple, un produit industriel, ça ne marche pas, ça. On ne peut pas faire un MVP comme ça. C'est-à-dire que si je développe une chaîne industrielle pour faire des trottinettes, demain, je ne peux pas avoir une chaîne industrielle pour faire des voitures. Ça, je l'ai vécu quand j'ai fait du hardware. Quand on fait des objets connectés, par exemple, il faut penser tout de suite l'objet qu'on veut faire. Donc voilà, il y a plein de cas et de produits, et vous serez confrontés dans votre carrière à des produits qui cocheront. Ce n'est pas exclusif, il suffit qu'il y en ait une case où ça ne marche pas et vous serez obligés de vous poser des questions et de construire votre méthode. Alors la première chose, qui est un point qui semble évident, c'est comprendre qui est dans ton équipe, avec qui tu vas travailler. Mais en fait, quand on sort d'une équipe traditionnelle où on a un développeur back-end et un développeur front-end, par exemple, en fait, il va falloir aller comprendre quel est le métier des gens avec qui tu développes ton produit. Je t'ai mis l'exemple d'hier, quand je suis arrivée chez Manili, j'ai découvert les data scientists. Leur boulot, c'est de développer les algos. Puis j'ai découvert le métier de machine learning engineer. Donc le métier, c'est pouvoir mettre les algorithmes en production. J'ai passé du temps avec eux, j'ai essayé de comprendre ce qu'ils faisaient, comment ça fonctionnait. Puis je me suis rendue compte que j'avais besoin de passer plus de temps pour que notre collaboration, elle soit efficace. Il fallait déjà, ça c'est le deuxième point, qu'on parle le même langage. Parce qu'en fait, c'est hyper spécifique, il faut comprendre les concepts. Je vous ai mis, typiquement pour un data scientist, quand il parle de machine learning et de deep learning, ce n'est pas la même chose. Il faut comprendre, il faut saisir cette nuance.
Je vous ai mis un autre point. Alors, accuracy, recall, précision, ça, c'est du langage purement de Data Scientist. Maintenant, ça commence à être un peu le mien aussi, je commence à avoir compris. Ce sont les façons de... Ce sont les métriques, seulement 3 métriques. Les métriques, en fait, c'est un outil mathématique pour évaluer les performances du modèle. On en parlait au départ sur notre petit modèle avec les chiens, les chats. On veut comprendre est-ce que notre modèle est performant. Le Data Scientist, il va utiliser ces 3 outils mathématiques qui s'utilisent différemment. Je ne vais pas vous faire un cours ce soir sur ça. Et en fait, si on n'a pas compris ces concepts-là, ça va être très compliqué de travailler au quotidien avec l'équipe. Donc la première chose, moi, ce que j'ai dû faire, c'est que j'ai dû me former. J'ai dû me former pour être capable de comprendre de quoi ils ont besoin, qu'est-ce qu'ils attendent de moi, et comment je peux discuter avec eux et qu'on se comprenne. Je voulais vous faire un petit rétexte aussi sur se former. Je me suis lancée dans un MOOC sur Coursera. J'ai mis une croix, ce n'est pas parce qu'il n'est pas bien. Mon retour d'expérience, c'est que c'était un gros MOOC. J'ai pris le Machine Learning, je pense hyper intéressant intellectuellement, parce que hyper riche, mais c'est 11 semaines de cours avec des travaux pratiques de code, et donc en fait très théorique, génial, sauf que je n'ai pas pu le finir. Alors, ne le cherchez pas, il n'existe plus, ils l'ont enlevé, ils ont rebrandé un peu les cours. Mais mon conseil, c'est... C'est hyper intéressant si on a le temps de le faire et de le pousser aussi loin, mais il faut essayer de trouver quelque chose qui soit très appliqué et qui va vous permettre de monter en compétence super rapidement. J'ai passé beaucoup de temps sur les métriques, je vous en parlais juste avant, là, ce Accuracy, Recall, Précision, c'est tellement important que j'ai essayé de lire tout ce que je pouvais sur le sujet. Dans les ressources, je vous partagerai aussi, Jonathan, le fondateur SEE Onemindy, il a écrit un super article qui, du coup, est hyper bien expliqué et vulgarisé pour comprendre comment ça fonctionne. Et donc voilà, il faut trouver des bonnes ressources pour aller lire et se former soi-même, parce que derrière, oui, vous allez pouvoir passer du temps avec l'équipe et leur poser des questions, mais il faut d'abord commencer par faire ses homework. C'est-à-dire qu'ils sont pas là pour vous former, et donc il faut faire l'effort soi-même au départ d'aller creuser, d'aller apprendre, pour ensuite se mettre sur un sujet avec l'équipe, poser des questions et continuer sa progression. Et ça, c'est ma dernière reco, c'est trouver tout de suite un projet qui va permettre d'appliquer tout ça pour que ce soit le plus concret. Et pour moi, ça a été ce projet d'extraction des lignes. C'est là où je me suis dit, ça y est, j'ai vraiment assimilé toutes ces notions que j'avais travaillées de façon peut-être un peu plus théorique. Alors après, je vais vous parler de... Une fois qu'on a tout ça, on a bien compris avec qui on travaille, on a établi une bonne collaboration, il faut faire du PM en fait avec son orga. C'est-à-dire qu'il faut comprendre les points de friction et les besoins. Après, je vais vous dire des choses que vous connaissez, mais je pense qu'on fait tous beaucoup de discovery avec nos utilisateurs, enfin, on essaye. Par contre, il faut le faire aussi avec son équipe et avec son organisation. C'est comme ça que vous allez comprendre quand... Typiquement, quand vous savez pas, quand vous pouvez pas appliquer des méthodes classiques, c'est comme ça que vous allez faire émerger où est-ce que vous pouvez créer de la valeur. Et donc, ça va revenir à ce que vous faites en discovery classique avec vos users, c'est poser des questions, faire des interviews, aller à un maximum de meetings, écouter, écouter, poser des questions, lire toute la doc qui existe pour essayer de voir où est-ce qu'il y a des trous, où est-ce qu'il y a de la friction, où est-ce que les gens pensent qu'on pourrait créer de la valeur. Et puis, voilà, vous allez faire ce que vous savez faire en tant que PM, c'est-à-dire lister les problèmes, les quantifier, les lier au business. Ça semble évident, mais je voulais vraiment le rappeler ce soir parce que je pense qu'on le fait pas suffisamment à son organisation et que je pense que c'est un levier hyper important pour créer très fortement de la valeur en tant que PM assez vite. Évidemment, à la fin, on veut identifier des solutions et c'est comme ça. Et en fait, on a utilisé tout ça chez Mindy pour développer la méthode ad hoc que je vous présentais juste avant. C'est-à-dire qu'on a passé du temps avec l'équipe de Data Science pour se dire, OK, c'est quoi les problèmes qu'on a, où est-ce qu'on peut... Quelles sont les attentes ? Et en fait, ce qui est ressorti, quand on a fait cette phase de discovery en interne, de toutes les discussions, on s'est rendu compte qu'on avait besoin, côté produit, de ramener de la connaissance utilisateur. C'est-à-dire que les Data Scientists, ils savaient très bien comment les clients utilisaient le produit, mais ils avaient besoin d'avoir encore plus de matières de compréhension dans le détail des cas d'usage. Et donc, on a dit, OK, on va passer plus de temps à vous proposer des contenus là-dessus, à faire des présentations. On a inclus tout ça dans la spec aussi. Ça, ça a très bien marché. On a compris qu'il fallait qu'on aille plus dans le détail aussi d'un point de vue produit sur c'est quoi les attentes des utilisateurs, c'est quoi les attentes en performance ? Quand est-ce que les utilisateurs sont contents ? Ou quand est-ce que les utilisateurs disent, non, mais pourquoi l'algo marche pas ? Là, ça va pas du tout. Et en fait, c'est en faisant tout ça, c'est-à-dire que ce que je vous raconte là, c'est pas théorique, c'est comme ça qu'on l'a construit. Et c'est comme ça que ça nous a permis de dire, bon, OK, une fois qu'on a bien posé ce qu'attendent les users, ben voilà, passons du temps à explorer la donnée, priorisons. Et c'est comme ça qu'on a construit toute notre approche. Et je dirais que le dernier point, et c'est le dernier point de la méthode, c'est il faut le mettre en place tout de suite. C'est-à-dire que ça doit pas rester théorique. Tout ce que vous allez découvrir dans cette phase-là, il faut l'appliquer, il faut identifier un projet pilote avec votre équipe sur lequel vous allez pouvoir mettre en place. Ça reste... Pour moi, c'est faire du produit sur son orga, c'est-à-dire que vous identifiez quelque chose à mettre en place, vous le testez, vous itérez, vous écoutez vos users et vous refaites l'itération d'après. Alors, si je résume un peu tout ce que je vous ai dit ce soir, parce que je vous disais, en IA, s'il y avait un takeaway, ça serait vraiment de repartir avec le... La data exploration, je pense que c'est le point le plus important et le plus intéressant à retenir, qui est vraiment un outil hyper puissant pour développer son produit. Maintenant, comme je vous disais, si demain vous vous retrouvez confronté à un produit sur lequel vous dites, je peux pas faire d'agilité, je peux pas faire de VP, etc., n'oubliez pas que votre skill principal, ça va être de vous poser des questions, poser des questions et trouver des problèmes à résoudre. En bon PM, vous savez le faire. Et voilà, je vous invite à regarder un peu les quatre piliers de la non-méthode. Ça pourra vous inspirer et vous donner un peu de matière sur comment commencer. Et n'oubliez pas de faire ce que vous savez faire en bon PM aussi. Itérez, continuez, c'est comme ça que vous y arriverez. Voilà. Merci. Applaudissements Merci, Emmanuel. Place aux questions. 15 minutes de questions. Est-ce qu'il y a des questions ? Oui, il va y en avoir. Amandine. Merci, Emmanuel. J'ai une question sur la première partie de ta présentation. Est-ce que c'est pas tentant d'ajouter des datas dans ton dataset de départ ? Parce que tu disais, vous vous en êtes resservi ensuite dans la déliverie. Du coup, si vous avez trouvé des nouveaux cas, est-ce que vous les avez ajoutés à tes 400 factures que vous aviez identifiées, ou tu restes vraiment focus sur ces 400 ? Non, en fait, c'est une très bonne question. C'est qu'en fait, ton dataset d'exploration, ce que tu veux, c'est qu'il soit le plus représentatif possible, et ce chiffre en fait de 400, alors il sort pas du chapeau. C'est qu'en fait, tu le choisis, il y a une notion de marge d'erreur, c'est que tu veux qu'il soit suffisamment représentatif, parce que tu te dis, je vais pas regarder 10 factures, si je regarde 10 factures, je vais pas avoir la réalité. Donc tu travailles, c'est des formules mathématiques, pour la marge d'erreur, donc nous, on avait dit qu'on en a 400, mais c'est toujours les mêmes 400 données que tu regardes. Donc dans la phase suivante, dans la phase de déliverie, ce que tu veux, c'est plutôt quantifier en fait. Donc tu vas réutiliser ça comme un outil statistique. Mais c'est pas une source de vérité non plus. Tu vois, c'est... Comment dire ? C'est vraiment à part. C'est-à-dire que tu vas pas rajouter de la donnée dedans, au contraire, c'est ta source de vérité, donc si tu viens le modifier, c'est que tu biaises finalement tout le reste. Donc tu dois vraiment le garder à part, tu n'y touches jamais. Tes 400 données que tu regardes, ce sont toujours les mêmes, et tu vas le réutiliser, mais toujours à l'identique. Merci. Merci beaucoup. J'avais une question. Justement, sur ce set de données 400, vous l'avez mis au début, un algorithme, il faut l'entraîner, j'imagine, sur des milliards de factures pour qu'il soit performant. Alors comment, sur ce milliard de données que tu as, sur lequel tu veux entraîner ton algorithme, tu en choisis 400 en fait ? Ouais, non, mais ça, tu les choisis de façon random, et puis ça, après, il y a aussi ce côté... Tu travailles avec l'équipe Data Science, c'est-à-dire qu'eux vont avoir la main sur toute cette partie statistique. C'est pas moi qui ai choisi les 400, tu vois. Moi, je suis là pour dire, il faut qu'on fasse cette data exploration, parce qu'en fait, moi, en tant que product, j'ai envie de comprendre ce que je veux exposer à mon utilisateur. Donc quand est-ce que... Parce que je veux avoir la main, enfin, je veux avoir la compréhension que c'est OK si on...
on ne résout pas ce cas-là, et c'est hyper important que ce cas-là soit bien traité. Donc après, notre boulot, c'est qu'on n'est pas les experts. Donc moi, après, c'est m'appuyer sur cette équipe de Data Science pour définir c'est quoi le bon volume de données à regarder et comment on les choisit. Tu vois, ça, c'est hyper important aussi. C'est-à-dire que c'est comme... Enfin, c'est aussi un point important, c'est que de la même manière que... Quand on travaille sur peut-être un produit plus cassis, qu'on n'est pas des experts front-end ou des experts back-end, en Data Science, c'est pareil, on ne va pas se substituer et on va vraiment en profiter pour s'appuyer. C'est eux qui ont cette connaissance des fonctionnements des modèles, des outils statistiques, et donc de comment... Enfin, je pense qu'il y a aussi une vraie conscience de ne pas biaiser les choses. Et ça, le Data Scientist, il est là pour être le garde-fou aussi, je trouve, sur... S'assurer qu'en fait, on n'introduit pas des biais dans la façon dont on regarde les données, dans la façon dont on prend des décisions. Et ça, pour ça, il nous rappelle en permanence, genre, non, mais attention, là, tu peux créer un biais, tu vois ? Merci beaucoup pour le talk. Je suis curieux, au niveau de la phase d'évaluation, moi, j'avais fait des trucs beaucoup plus simples, qui n'utilisent pas de la computer vision et tout, mais est-ce que tu as eu des cas où tu pensais que tu étais bien parti sur ton évaluation de ton modèle ? Et en fait, en le réentraînant, t'as créé des régressions ou ce genre de mauvaises surprises, parce que ton évaluation de modèle était potentiellement basée sur les mauvais critères, ou ce genre de choses, vu que c'est un peu plus black box, plus difficile à tester. Est-ce que t'as peut-être des enseignements à partager de ce côté-là, sur les surprises que tu peux avoir ? En fait, ton évaluation de modèle, elle est continue. Est-ce que t'essayes... C'est pour ça que je parlais de l'article, il y a plusieurs choses dans la partie découpage MVP. Je vous ai montré la partie qualitative, c'est-à-dire comment on essaye d'évaluer à quel point notre modèle y performe sur les cas que nous, on s'est fixés, sur lesquels on veut que ça marche bien. Donc ça, c'est ce que je vous ai montré. Et ce que j'évoque dans l'article, c'est que ça, c'est qualitatif, mais il y a une partie quantitative. Je voulais pas rentrer ce soir dans le détail des métriques, mais moi, j'ai appelé ça les minimum viable metrics. C'est que dès le départ, en fait, ce qu'on veut, c'est être capable de se dire, c'est quoi les métriques qui vont être acceptables ? Déjà, je vous ai montré les 3 métriques, c'est quoi la métrique qui va être importante dans le cas d'usage sur lequel on travaille ? Déjà, on fixe ça en amont. Et puis après, ce qu'on fait, c'est de se dire, ça serait quoi, qu'est-ce qui va être acceptable ? Et ça, on va itérer dessus. Donc on essaye d'avoir un peu, pour moi, les 2 approches sur cette partie-là, pour essayer de voir quand on progresse, est-ce qu'on progresse sur la résolution de certains problèmes ? En fait, c'est ça que t'as envie de voir, c'est quels sont les problèmes, les nouveaux problèmes que je découvre dans ma phase de développement, et est-ce que je veux les supporter ? Et puis, du coup, tu peux revenir à l'aspect statistique, tiens, ce problème-là que j'ai, est-ce que je passe du temps à le résoudre ou pas ? Parce que je ne l'avais pas forcément anticipé en phase de spec. Merci, c'était très intéressant. J'avais une question, toujours sur le set de data. Est-ce que c'est celui-là que vous utilisez pour entraîner, finalement, l'IA ? Est-ce que les 400, c'est ce que vous allez utiliser pour avoir vrai ou faux ? Parce qu'avec les chats, c'est facile. Ce que vous avez montré, c'était assez simple. Dire c'est un chat, on sait le résultat, donc c'est comme ça qu'on apprend. Du coup, il faut avoir les informations de qu'est-ce qu'on attend comme résultat pour chaque facture et est-ce que c'est juste ou est-ce que ce n'est pas juste ? Comment vous avez fait pour créer ce test, ces tests ? Alors, il y a plusieurs choses. Il y a la partie données à noter, donc pour entraîner ton modèle, t'as besoin de données à noter, c'est-à-dire des factures où tu dis, tel champ, c'est tel résultat. Voilà ce qu'il y a sur le document. Donc ça, que ce soit des chats ou des chiens ou des factures, finalement c'est la même chose. Après, le dataset d'exploration, c'est un dataset qui est à part, où t'as pas besoin d'avoir les labels puisque finalement, c'est moi qui regarde et qui essaye d'extraire des patterns. Donc c'est encore autre chose, tu vois. Vous avez utilisé ces données-là que t'as extraites justement pour en profiter, pour dire est-ce que le modèle, il trouve la même chose que toi t'as trouvé ou est-ce que ça... Alors après, les 400 données, ce qu'on a envie, c'est de se dire, on le sort et c'est pour l'EPM et c'est un outil d'exploration. Après, en machine learning, t'as la notion de dataset de validation et de test. Et en fait, ce que tu veux surtout, c'est bien faire une différence entre ce que t'as utilisé pour entraîner, ce que t'as utilisé pour valider ton modèle et qui va te permettre de continuer d'itérer sur ton modèle et ton dataset de test qui doit être juste pour voir où t'en est. Et les data scientists sont très strictes sur le fait que tu ne réutilises pas des données que t'as utilisées dans le training pour tester, etc. Merci. Je suis assez curieuse de comprendre comment tu as géré ce que tu as mentionné, la certitude d'aboutir au sein de ton organisation, que ce soit auprès de ton équipe de développement, auprès de ton PDG et CIO et auprès de tes clients. Alors, l'incertitude, c'est un peu un point extrême. C'est qu'en fait, on essaie de dérisquer ça. Et puis, chez Mindy, ces technologies de computer vision et d'extraction de données font ça depuis 4 ans. Donc, je pense que c'est aussi différent. T'as pas un risque d'échouer complètement. Ce que t'essayes de voir, c'est de dérisquer, en fait. Donc, le plus tôt t'arrives à avoir un modèle qui te donne les premiers résultats, le plus tu te rassures dans le fait que tu vas réussir à atteindre les objectifs que tu t'es fixés. Donc, c'est... Je dirais que c'est pas tant de manager... En fait, quand tu fais de la data science, ce point-là, tout le monde le connaît, en fait. Tu vois, les data scientists, ils le connaissent. Le CIO le connaît. De toute façon, c'est quelque chose qui est partagé par tous au départ. Donc, on a un objectif commun de se rendre compte très rapidement des problèmes. Et c'est ça qu'elle permet, cette méthode, en fait. Elle permet de se dire, OK, comment on découpe ? Sur quoi on met de l'effort ? Où est-ce qu'on veut être sûrs qu'on crée beaucoup de valeurs au user ? Et du coup, on perd pas du temps à résoudre plein de choses, plein de cas qui, peut-être, sont moins importants pour le user. Donc, finalement, on le partage tous au départ, de se dire, ouais, peut-être qu'on va rencontrer des problèmes et on les connaît pas tous. Mais du coup, l'approche de se dire, on regarde bien dès le départ tous les cas qui vont poser problème. Est-ce qu'on veut passer du temps dessus ? Ça nous dérisque déjà, quoi. Donc, finalement, t'as pas d'enjeu de communication, forcément, parce que tout le monde est dans le même bateau. Et je dirais que moi, finalement, je suis arrivée après tout le monde. Les data scientists, c'est leur métier. Moi, j'ai découvert ça en faisant de l'IA. Mais ça te donne plus envie de dire, OK, qu'est-ce que je peux mettre en place, moi, pour que ça nous facilite la phase de développement et qu'on puisse se rassurer dans les différentes itérations qu'on va avoir. Bonsoir, Emmanuelle. Déjà, bravo pour la praise. Je l'ai trouvée très réussie avec une mention spéciale pour les icônes et les émojis. Tout à fait. J'y ai passé beaucoup de temps. Donc, ma question, là, on est sur un meetup French Produits. French Produits, c'est l'entraide, les conseils entre pairs. Et quand tu es sur un produit qui, justement, sort un petit peu du moule, rentre pas dans le moule, est-ce que tu arrives à trouver à l'extérieur, est-ce que tu arrives à trouver à l'extérieur, justement, des conseils, des entraides sur comment faire ? T'as toujours de l'entraide dans la communauté, ça, c'est clair. Je pense que... Et en fait, je dirais que notre métier, c'est de résoudre des problèmes. Donc, finalement, que le problème soit un problème user ou un problème de méthodo, c'est plus notre capacité à se dire, OK, c'est quoi les problèmes qu'on a et de qui j'ai besoin pour essayer de résoudre les problèmes ? C'est pour ça que le côté se poser des questions, c'est assez universel et que si tu te poses des questions, tu vas trouver la bonne approche. Que tu te poses des questions à toi-même pour te challenger sur quelle est la bonne méthode ou que t'ailles voir tes copains de la communauté, c'est à toi de trouver finalement les bonnes ressources sur le problème que tu veux craquer. Donc oui, la communauté, elle peut t'aider. Maintenant, je trouve... C'est aussi comment trouver des gens qui ont été confrontés au même problème que toi. Et c'est aussi l'idée d'écrire du contenu, de venir faire des talks, c'est de dire, voilà, j'ai fait ça, n'hésitez pas à me solliciter si je peux vous aider, parce que c'est aussi pour ça l'objectif de ma venue ce soir, c'est de dire, voilà ce qu'on a expérimenté sur l'IA, si vous en faites demain et que vous posez des questions, venez me voir, si je peux vous aider, je le ferai. J'ai fait de l'IoT, c'était pareil, c'est encore assez nouveau, et c'est l'objectif de venir partager, c'est aussi ça. C'est aussi de dire, si on peut give back to the community, c'est top. Oui, une ou deux dernières questions, peut-être ? J'ai une question, merci beaucoup pour la présentation. Une question par rapport à l'architecture. J'ai peut-être mal compris, je ne sais pas si vous en avez parlé, mais votre projet, c'était un projet un peu transverse pour toutes les équipes, donc c'était un peu technical product manager. Et aussi comment vous avez géré, vous avez dit que ce n'est pas une MVP, donc c'est un gros...
avec un final, avec un fond assez précis. J'imagine que ce n'était pas des sprints. Comment vous avez travaillé avec d'autres équipes en parallèle ? Quel était leur gars ? C'est un projet, je dirais qu'il faut le prendre comme un projet classique, un produit classique. On veut développer une fonctionnalité qui permet d'extraire les lignes des factures. C'est une feature dans un produit. Moi, en tant que PM, j'ai animé mon équipe de la même manière. Même si je n'avais pas des sprints, c'est-à-dire qu'on n'arrivait pas avec une démo le vendredi, parce que tu n'as pas forcément quelque chose à montrer, parce qu'il faut potentiellement plus de données à noter pour que tu puisses entraîner ton modèle. Entraîner un modèle, ça prend du temps. Donc on n'a pas toujours quelque chose à montrer. Mais par contre, avoir une cadence où on se voyait toutes les semaines pour se dire voilà ce sur quoi on a bossé, ce problème qu'on a rencontré, ça permet de faire émerger, de voir s'il y a des roadblocks. Après, c'est à toi de trouver quelle est la bonne façon d'animer ton équipe. L'agilité te donne un cadre. Maintenant, tu peux reprendre cette approche-là, de se dire on fait un weekly meeting juste pour se donner un peu les priots de chacun, voir si quelqu'un est bloqué, brainstormer quand il y a des sujets. Moi, j'utilisais ce côté quand même d'avoir un weekly, ce qui nous permet d'avoir un point d'étape où on peut se voir et on peut échanger. Même s'il n'y avait pas forcément quelque chose de concret, un modèle qui tourne où tu peux voir ce qui se passe. Parce que ça, ça a pris beaucoup plus de temps. Merci Emmanuelle. J'ai une question. Au-delà du cœur technologique IA que tu as décrit, est-ce qu'il y avait d'autres services dans le produit back, front, une API à faire évoluer dans un mode plus classique avec des cycles plus classiques, courts ? Comment tu faisais cohabiter ces cycles IA un peu particuliers et le reste du produit ? Mindy, ça propose des API. Je vous ai parlé des factures, mais ça propose aussi des API pour les reçus. Il y a tout un tas de produits, des produits pour construire sa propre API d'extraction d'informations. Et il y a une plateforme sur laquelle tu peux venir créer ton compte, entraîner ton modèle quand tu veux créer ta propre API. Donc en fait, ça oui, tout continue de vivre en parallèle. Et ce qu'il faut quand tu développes une nouvelle fonctionnalité comme ça, c'est anticiper qu'est-ce qui va se passer le moment où le modèle est prêt et qu'on veut le mettre en production. C'est quoi les impacts ? C'est quoi les impacts sur la plateforme ? C'est quoi les impacts sur la documentation ? C'est quoi les impacts sur la sortie de l'API, etc. Donc le rôle du PM, ça va être de penser un peu à tout ce qui va arriver après et de l'anticiper pour que justement, au moment où le modèle est prêt, tout ce qu'on doit faire derrière est préparé un maximum puisqu'on sait que cette phase avant de développer un modèle qui fonctionne va prendre du temps. Je pense qu'il n'y a plus de questions. C'est nickel. Et je pense qu'on peut réapplaudir Emmanuel. Merci beaucoup. Merci beaucoup. Merci beaucoup. Je pense aussi que vous avez eu le temps de lire la slide. Évidemment, feedback is a gift. Si vous pouvez donner un petit retour sur le meetup, ça nous aide grandement à l'améliorer avec l'équipe. Et maintenant, place à la deuxième partie de cette soirée bière, pizza, réseautage. C'est un bon résumé. C'est au premier étage de ce bâtiment, évidemment. Merci à tous d'être venus encore. Merci.