LA MESURE DE LA QUALITÉ GRÂCE À L'IA

– Marc — 00:00 :

 Aujourd’hui, je reçois Alexandre Hannebelle, ex ingénieur spécialisé en machine learning. Il commence sa carrière dans la start-up Ava à San Francisco pour créer un système de reconnaissance vocale pour les sourds et malentendants. Après 4 ans sur ce premier projet, il rejoint inax et Ed of Data Science depuis un peu plus de 3 ans. Bonjour Alexandre. 

– Alexandre — 00:19 :

 Bonjour Marc, merci pour ton invitation. 

– Marc — 00:21 :

 Mais avec plaisir, est-ce que tu peux nous parler un petit peu d’ina X que vous faites un peu plus dans le détail? 

– Alexandre — 00:26 :

 Bien sûr. Alors notre objectif, c’est de transformer les smartphones. En laboratoire de poche pour les agriculteurs et les coopératives pour leur permettre de mieux contrôler leurs qualités et de mieux valoriser leur production. Je peux parler du premier produit qu’on a développé, donc c’est un système de reconnaissance de la variété de l’orge. Alors je pense que tout le monde le sait pour faire de la bière, il nous faut du malt, donc c’est des graines germées, souvent de l’orge et ce qu’on sait peut-être moins, c’est que pour le processus de maltage, y a besoin d’avoir en entrée des lots d’une seule et même variété. Il y a pas forcément une variété qui est mieux que d’autres, mais il faut que l’ensemble soit homogène. Pour que le processus de transformation permette à toutes les graines de germer, de malter en même temps. Le problème c’est que c’est assez difficile de contrôler cette variété. C’est difficile de les distinguer à l’œil nu et donc notre système permet à n’importe qui de prendre en photo un petit échantillon du lot et de savoir la composition variétale. 

– Marc — 01:19 :

 Donc vous allez vous concentrer sur la qualité et l’état d’avancement du germe, c’est ça là, 

– Alexandre — 01:25 :

 C’est vraiment qualifié. Le lot en amont, donc on s’intéresse pas encore au processus de maltage en lui-même. C’est vraiment s’assurer que le lot est homogène en variété donc, qui correspond bien au cahier des charges des malteurs pour qu’ensuite eux puissent de leur côté appliquer leur transformation habituelle. 

– Marc — 01:40 :

 D’accord et vous avez un 2ème produit maintenant, c’est ça alors on en a beaucoup, on en a pas loin d’une dizaine. Quelques exemples, ça peut être la variété de blé. Une estimation du taux de protéine sur blé ou sur orge, essayer d’estimer le taux de grain cassé, qui est un critère aussi important, par exemple pour la conservation du blé. 

– Marc — 01:58 :

 Alors vous êtes un produit data par excellence, ce que tu peux nous parler de la data chez vous commence à organiser qui et à quoi ça sert? 

– Alexandre — 02:06 :

 Alors, s’occuper de la data, c’est l’occupation principale de beaucoup de monde chez Nyx, donc la data, ça commence à l’acquisition donc ça se passe avec notre application Pocket Lab. L’enjeu c’est de fournir une interface pour que nos utilisateurs puissent facilement acquérir la data, donc prendre des photos et nous indiquer des informations à propos de l’échantillon qui sont en train de mesurer ça peut être la variété, ça peut être le lieu où ça a poussé par exemple. Donc la première étape, voilà, c’est capter cette information et ensuite on a un gros enjeu au niveau du stockage et en particulier de rendre toute cette information accessible facilement. On a beaucoup de sources de données, on a des produits différents, des espèces différentes, des sources de données différentes et on a besoin d’être capable ensuite de facilement retrouver nos petits. Quels sont les photos pour lesquelles on a une information sur la variété ou sur le taux de protéine, et cetera? Et on a aussi beaucoup d’utilisations, donc beaucoup de photos et un gros enjeu, être capable de récupérer toutes ces informations rapidement. Cette partie là chez nous, elle est plutôt gérée par l’équipe Software qui s’occupe de la mise à disposition de ces données et ensuite notre travail commence et la première étape pour nous, c’est de qualifier toute la donnée qui a été stockée, donc on va essayer de rajouter un certain nombre de descripteurs par-dessus pour indiquer par exemple quelle est la qualité de la photo. Il y a des gens qui sont flous ou pas. Est-ce que c’est bien les la bonne espèce? On s’attend à avoir de l’orage ce que c’est effectivement de l’or sur la photo, est-ce qu’on a des présences d’impureté par exemple, et on essaie de plus en plus de rajouter donc ce qu’on appelle des descripteurs. Ça va être un vecteur, une suite de nombres un peu abstraites, mais qui nous permet d’indiquer de stocker des informations sur le contenu de l’image et derrière, ça permet de faire des recherches de similarité par exemple. Et enfin, la dernière étape, c’est d’utiliser toute cette donnée pour créer nos modèles de machine learning qui ensuite sont capables de faire des mesures d’orge, de blé d’après les photos. 

– Marc — 03:57 :

 Alors, c’est quoi ton quotidien? Donc je suis un sujet comme celui-là, of datas, à quoi ça ressemble? 

– Alexandre — 04:03 :

 Alors je dirais qu’il y a 3 grandes composantes. La première, ça va être la gestion de l’équipe data Science. La 2ème, ça va être des contributions techniques individuelles et la dernière c’est collaborer avec les autres équipes au sein de l’entreprise. Donc pour la gestion de l’équipe, ça peut être le recrutement, ou alors vraiment le la gestion RH de l’équipe, ça va être organisé le, et distribuer le travail, donc on a un système qui ressemble au sprint du fonctionnement Agile de Software, donc toutes les 2 semaines ont fait une réunion, un planning, et cetera. Ensuite, pour la contribution individuelle, c’est beaucoup s’assurer que l’on suit bien l’état de l’art, donc je passe beaucoup de temps à lire des papiers, à aller aller, à des conférences pour être sûr que notre recherche s’appuie bien sur cette étude là et ensuite je vais travailler plutôt sur des sujets de fond un peu. De long terme, je dirais sur quelques points que je considère stratégique pour essayer de lever des verrous importants. Et enfin la collaboration avec les autres équipes de l’entreprise. Ça peut être porté la voie de la data pour l’orientation stratégique de l’entreprise, ça peut être aidé à concevoir les produits ou aider à mettre en place les process pour s’assurer que tout fonctionne bien dans l’utilisation des produits en production. 

– Marc — 05:19 :

 Alors dans le domaine de la data, ce que tu peux nous partager des décisions business qui auraient été pris grâce à la data grâce à l’observation de la data. 

– Alexandre — 05:27 :

 Alors, il y a quelque chose dont on s’est rendu compte un peu par hasard, en creusant comment fonctionner nos modèles? C’est qu’on s’est rendu compte qu’il y a certaines propriétés qui émergeaient de nos modèles, sans qu’on ait forcément décidé de les créer. Donc je m’explique. Pour faire les prédictions ou les mesures. D’après les images, les modèles font une forme de représentation interne de ce qu’ils voient. On appelle ça des embeddings et on s’est rendu compte qu’en regardant ces embeddings du point de vue du modèle, les échantillons d’orge qui ont poussé un certain endroit un certain moment ressemblent ont des embeddings similaires aux orges qui ont poussé à peu près. Au même endroit et au même moment et sont différents d’orges qui ont poussé à un autre endroit dans le pays par exemple. Et ça, c’est très intéressant parce que ça nous permet d’imaginer des produits qu’on aurait pas forcément imaginé faisable à court terme. Un exemple très concret, c’est la traçabilité. En utilisant, voilà ce genre de propriété, on peut être amené à voilà être capable de déterminer que ce lot qui arrive à la coopérative ou au Meunier ou chez le malheur. Ben oui, il vient bien de cet endroit, il a bien poussé à tel moment, ou alors peut-être qu’il y a eu une erreur. Avoir quelqu’un qui a été mal intentionné à un moment et essayer de réintégrer dans des filières de la matière qui n’aurait rien à y faire. 

– Marc — 06:44 :

Et là y a aucune question d’espèce, c’est la même espèce de graine, c’est les mêmes graines qui poussent à 2 endroits différents et on va être capable de le voir avec la Computer Vision qu’elles ont elles ont pas poussé  Au même endroit 

– Alexandre — 06:54 :

alors non, bien sûr, ça va être spécifique par espèce, on va comparer de l’or avec de l’orge, du blé avec du blé, voire même par variété. Il faudra distinguer. Voilà cette telle variété d’orge et telle autre variété d’orge. A priori en tout cas à court terme, on n’aurait pas de capacité à mesurer de façon absolue. Ça, c’est des graines qui ont poussé à tel endroit. En France, les marqueurs sont trop différents selon les espèces, voire les variétés. 

– Marc — 07:18 :

 D’accord, mais pour la même variété, vous voyez des différences suffisamment? Importante pour qu’on les voit avec un smartphone entre 2 régions françaises. 

– Alexandre — 07:28 :

 Ouais c’est ça, oui. 

– Marc — 07:29 :

 D’accord et ce que tu peux nous décrire. Une utilisation typique de votre produit de Computer Vision et de détection de variétale d’orge. 

– Alexandre — 07:37 :

 Oui, alors, dans 2 mois l’environ il y a la récolte d’orge qui va commencer et donc les agriculteurs vont apporter leur récolte camions par camion à une coopérative le plus souvent, et quand le camion arrive, il y a un certain nombre de mesures qui doivent être faites et donc ce qui se passe c’est que roule là-bas au-dessus du camion, il y a un grand bras articulé. Qui vient aspirer un petit peu de grain à 3 endroits du camion. Ce grain arrive dans une sorte de petite salle au-dessus tombe dans un seau. Et là les opérateurs prennent un petit échantillon qui utilisent pour mettre dans un certain nombre de machines qui font chacune leur propre mesure et en mettre une partie dans une barquette, prennent le smartphone dédié et prennent quelques photos avec l’application a garics. Ces photos sont ensuite envoyées sur nos serveurs et c’est là qu’on fait les mesures. Les prédictions avec nos modèles pour les critères qui correspondent à cette utilisation. Et ensuite, en fonction des résultats qui ont été affichés, l’opérateur peut prendre une décision opérationnelle qui peut être typiquement d’orienter ce camion vers tel ou tel cellule de stockage. 

– Marc — 08:35 :

 Ok aujourd’hui, le paysan pourrait pas lui-même prendre son smartphone et prendre le grain en photo pour avoir une idée un petit peu en avance de la qualité de son grain et de ses revenus de l’année. 

– Alexandre — 08:47 :

 Oui, bien sûr, c’est un très bon point. C’est d’ailleurs un gros enjeu pour nous, c’est d’être capable de multiplier les mesures. La raison principale pour laquelle ce que ça c’est pas fait aujourd’hui, c’est que les machines existantes sont lourdes, coûtent chères, sont difficiles à déplacer, et cetera. Donc c’est ça qui va venir vraiment. Contraindre le nombre de mesures qui sont faites, nous le dans le système qu’on propose. On s’appuie sur un hardware qui est existant, qui est déjà présent à peu près partout et le but c’est bien évidemment qu’on puisse faire des mesures un peu partout et tout le temps. Il y a un certain nombre de verrous technologiques à lever pour être capable de faire ça. On en parlera plus tard et c’est effectivement l’enjeu, oui. 

– Marc — 09:25 :

 Ok parlons-en justement, les verrous technologiques, quels sont les? Les voilà, les obstacles que vous avez rencontrés, comment vous les avez traités? 

– Alexandre — 09:33 :

 Donc, le premier verrou, la première grosse difficulté, c’est la grande diversité de smartphones qui existe. Il y a voilà beaucoup de constructeurs, beaucoup de modèles différents et ils vont tous utiliser du hardware différent. Un capteur photo différent? En plus, il y a beaucoup. Il commence à avoir de plus en plus de couches logicielles qui sont rajoutées de traitement d’images de préprocessing pour les rendre plus jolies, et cetera. Ce qui fait qu’un même grain pris en photo avec différents téléphones peut avoir des aspects vraiment très différents. Et donc le gros enjeu pour nous, c’est d’être capable de généraliser au travers de tous ces téléphones, et donc d’être capable d’apprendre à reconnaître telle variété sur des photos d’un téléphone et ensuite avoir un système qui fonctionne bien sur un autre téléphone. Un 2ème verrou qui est assez lié, c’est tout l’impact de l’environnement, de l’éclairage. Et ça comme voilà. Encore une fois, l’objectif, c’est que les photos puissent être prises simplement facilement partout. On n’a aucun contrôle là-dessus et c’est vraiment un choix qu’on fait d’englober toute la complexité et de mettre. Le moins de contraintes possibles sur les utilisateurs et la dernière difficulté, c’est qu’on travaille avec du vivant et donc tout change tout le temps en fonction de la météo. Il y a des nouvelles pratiques, agricultural, des nouvelles réglementations, et cetera. Et donc on a pu lever une partie de ces verrous, mais on a encore pas mal de travail à faire là-dessus. Et finalement, le fait de mettre peu de contraintes sur les utilisateurs fait que dans la donnée qu’on récupère contient déjà beaucoup de variabilité et ça nous aide beaucoup pour incorporer. Cette capacité à généraliser dans les modèles. 

– Marc — 11:07 :

 D’accord donc les modèles, vous êtes obligé un peu de les mettre à jour constamment en fonction de l’évolution des normes agricultural sales. 

– Alexandre — 11:16 :

 Oui, et c’est quelque chose qu’on a vraiment pensé dès le début dans notre vision des choses, on crée pas vraiment des modèles de machine learning, on crée presque une usine qui va être capable de générer très régulièrement, de mettre à jour très régulièrement tous ces modèles, donc en période intense de récolte par exemple. On va voir bah voilà, le c’est la première fois qu’on voit cette variété telle année, et cetera. On va avoir des entraînements qui sont quotidiens sur tous nos modèles et on peut avoir un à plusieurs déploiements en production tous les jours et ça, c’est un gros avantage par rapport à d’autres technologies existantes. Cette capacité à absorber la nouvelle variabilité en quelques heures sur tout le territoire. 

– Marc — 11:55 :

 Est-ce que vous avez au niveau on va dire au opérationnel, est-ce que vous avez des urgences en machine learning ou est ce qu’on est sur de la R et D qui sera déployé plus tard, et cetera? Ce que ça vous arrive d’être face à une nouvelle situation? Il faut la régler vite oui, quand même de moins en moins, heureusement, mais il y a quand même toujours ça situe principalement à des moments où il y a de la nouvelle donnée, donc un début de récolte. Voilà une nouvelle variété, et cetera. C’est là où il faut que nous, on s’assure que nos méthodes qui ont été calibrées sur le passé fonctionnent encore aujourd’hui et souvent ça se passe bien, mais y a toujours des cas particuliers qui n’ont pas été prévus, et cetera. Et c’est là, on a besoin d’intervenir très vite parce que sur le terrain les choses vont très vite et suffit d’avoir. Quelques minutes où les systèmes ne fonctionnent pas pour avoir tout de suite une queue de camion devant les coopératives, il faut qu’on soit très réactif. 

– Marc — 12:51 :

 Alors, ce qui est le plus important pour toi dans les travaux de machine learning? 

– Alexandre — 12:55 :

 Alors je dirais pour nous en particulier, comme on travaille avec des images, c’est de rester très proche de l’état de l’art. Je pense que tout le monde l’a à l’esprit. Les choses avancent très vite en ce moment et donc il faut être capable de pouvoir incorporer facilement toutes les nouvelles avancées. Et pour moi, l’enjeu, c’est d’être capable de faire la part des choses entre dans notre application, dans notre problématique technique, qu’est-ce qui est spécifique à notre problème et qu’est ce qui est générique et ce qui va être commun avec d’autres problèmes? Et l’enjeu, c’est d’être capable d’utiliser des solutions génériques pour des problématiques qui sont génériques et uniquement faire un travail dédié. Pour ajuster les modèles, les systèmes à nos spécificités et je remarque qu’on a souvent tendance à croire qu’on travaille sur quelque chose de très unique, très spécifique, différent de tout le reste. C’est souvent partiellement vrai, mais y a quand même beaucoup de choses qui sont génériques et qu’il faut surtout pas redévelopper en interne parce que ça va être balayé par la prochaine amélioration. 

– Marc — 13:56 :

 De l’état de l’art, c’est un exemple en tête de quelque chose qu’il faut pas faire en interne et que vous avez repris. 

– Alexandre — 14:02 :

 Par exemple, travailler sur une architecture de modèle. Entre voilà un réseau de neurones convictionnels, tel nombre de couches ou alors changer un petit peu le fonctionnement du vision. Transformer, voilà, c’est des architectures qui sont très génériques, qui sont déjà bien paramétrées, et cetera. Pour moi, ça a aucun sens de travailler là-dessus. 

– Marc — 14:21 :

 Alors, comment est-ce que tu estimes à l’avance combien va prendre un travail de recherche? Une tâche de recherche quand ça te tombe dessus? 

– Alexandre — 14:30 :

 Je trouve ça très compliqué. Je dirais qu’il y a un peu par rapport à des problèmes. Software a une double incertitude. Il y a une incertitude qui est liée au temps qu’on va mettre à implémenter une feature à implémenter quelque chose et il y a ensuite une incertitude sur le nombre d’itérations de recherches qui vont être nécessaires avant d’atteindre une certaine performance. Donc on a un peu une démultiplication de l’incertitude. La seule chose que j’ai un petit peu trouvée pour remédier à ça, c’est d’essayer d’avoir des objectifs qui sont pas tant en termes de performance absolue, mais plutôt en termes d’effort, donc en par exemple en nombre d’itérations qui ont été faites sur un produit pour améliorer la performance. 

– Marc — 15:08 :

 D’accord, donc tu vas essayer d’estimer le nombre d’itérations? Nécessaire pour arriver à l’objectif? 

– Alexandre — 15:13 :

 Bah donc je commence par estimer le nombre d’itérations qu’on peut faire dans un temps donné et ensuite le nombre d’itérations nécessaires pour arriver à l’objectif. Ça, je trouve que c’est assez peu estimable et donc on est un petit peu obligé de voir au fil de l’eau, je dirais. 

– Marc — 15:27 :

 D’accord, une itération pour toi, c’est un sprint 2 semaines. 

– Alexandre — 15:31 :

 Oui, ce sera cet ordre de grandeur. 

– Marc — 15:32 :

 D’accord, alors comment tu choisis tes recrues? Quels sont les profils que tu recrutes? 

– Alexandre — 15:37 :

 Il y a un petit peu 2 phases. Une première phase qui se termine dans cette phase là. J’ai recruté plutôt des profils assez généralistes, je dirais des data scientists qui ont une formation d’ingénieur avec un background mathématique assez important. Dans le choix des personnes que je recrute, je fais très attention à ce que j’appellerais un bon sens scientifique. Je sais pas si c’est un très bon nom, mais c’est la capacité à poser les bonnes questions, à repérer les choses qui sont anormales sur lesquelles ça vaut le coup de passer du temps. Voilà, c’est peut-être des réflexes de chercheurs et tout en demandant aussi une certaine habitude du code, ce qui est pas toujours le cas dans nos formations d’ingénieur, on entame une 2ème phase dans laquelle on cherche à diversifier un petit peu nos profils. Et donc d’avoir plus de profils qui ont une expérience dédiée en data, analyse par exemple. 

– Marc — 16:28 :

 Quel a été ta plus grande déconvenue? Que la data. 

– Alexandre — 16:31 :

 Alors y a un Pattern qui arrive régulièrement je trouve, c’est voilà, on commence sur un nouveau produit, un nouveau use case, donc on va chercher un premier dataset. On a bien appris nos leçons, donc on divise ce dataset en un data set d’entraînement, un data SET de validation et on obtient un modèle qui est très bon sur le set de validation et donc ensuite Ben on prend ce modèle, on considère qu’il fonctionne bien et on le déploie. Et on observe que, en production, ça marche beaucoup moins bien, donc c’est assez lié à ce qu’on a du data drive, du domaine Shift. Tous ces termes là qui cherchent à décrire le fait que c’est très difficile de capturer toute la variabilité dès le début. Et voilà, y a pas de solution, j’ai pas encore trouvé de solution miracle pour remédier à ça. Une des directions que je vois c’est qu’il faut être capable d’incorporer une forme de bon sens générique, je dirais dans les modèles pour qu’ils soient capables d’ignorer des facteurs de variation qui n’ont pas de sens. Par exemple dans notre cas, on sait très bien que le modèle ne devrait pas être sensible au smartphone qui a été utilisé pour prendre la photo à l’éclairage. 

– Marc — 17:33 :

 Et alors, comment tu fais? Dans le cadre du Deep Learning ou Ben, on a très peu la main sur l’algo lui-même, hein. Comment tu fais pour forcer cette généricité face à une variable que tu veux éliminer? 

– Alexandre — 17:46 :

 Moi, je trouve qu’on a quand même pas mal la main. Déjà, on a le choix des d’attaques sur lesquels on entraîne les modèles. Nous, notre chance, c’est que notre data d’entraînement est produite par l’utilisation de notre produit et donc on peut jouer sur beaucoup de paramètres à ce niveau-là. Ensuite, je dirais que la recherche aujourd’hui en machine learning travaille vraiment spécifiquement sur ce bon sens un peu générique sur la généralisation et donc il commence à y avoir beaucoup de techniques qui permettent d’avoir ce genre de propriété. 

– Marc — 18:13 :

 Ce que tu regrettes de pas avoir fait autrement. 

– Alexandre — 18:16 :

 Ce serait dans la priorisation des choses à essayer jusqu’à maintenant. On a essayé de prioriser les idées en amont en gardant celles qui ont le plus de chances de marcher. Sauf qu’on fait cette priorisation d’après une certaine intuition qui est parfois juste et parfois non, et je pense que ce que j’aurais aimé faire c’est plutôt passer du temps à développer notre capacité de tester beaucoup d’idées, donc en construisant des outils par exemple pour se donner plus de chance de tomber sur l’idée contre-intuitive mais qui fonctionne? 

– Marc — 18:46 :

 Quand est-ce que t’es le plus content de ce que tu fais? 

– Alexandre — 18:48 :

 Alors j’appelle ça des euréka. Moment c’est souvent après avoir passé beaucoup de temps, peut-être 6 mois ou un an à construire des outils pour pouvoir mieux observer ce qui se passe. Et d’un coup les choses se mettent à fonctionner et ça peut être une nouvelle approche un peu originale qui voilà d’un coup se met à fonctionner. J’ai une image pour décrire ça et je m’imagine en train de d’essayer de démêler une pelote de laine par exemple tout emmêler. On y arrive pas en tournant rond et puis d’un coup on défait quelque chose, une boucle. Et puis tout devient facile quoi. Tout se démêle, ça arrive pas très souvent, c’est une ou quelques fois par an, mais c’est toujours des moments assez. 

– Marc — 19:24 :

 Sympas, faut faire gaffe parce que des fois après comme tu dis en production ça fait pas le même effet et à l’inverse, qu’est-ce qui te frustre le plus? Quels sont les moments et les moins sympas dans ce métier? 

– Alexandre — 19:35 :

 Les moments difficiles, je trouve, viennent du fait que j’essaie de concilier des problématiques de production opérationnelles. Assez court terme avec de la recherche qui est plus long terme. Et donc voilà, je suis tiraillée entre des urgences et une envie de prendre le temps des journées entières ou des semaines entières sans interruption pour vraiment rentrer dans la complexité, essayer de comprendre ce qui bloque. Et voilà, personnellement, je trouve ça pas si facile à gérer. 

– Marc — 20:03 :

 Ce que t’as une anecdote à nous partager? 

– Alexandre — 20:05 :

 Alors les premières récoltes qu’on a passées, alors forcément, on avait beaucoup de choses qui étaient faites manuellement, donc on était sur le pont un peu tout le temps et à la fin de cette récolte, on s’était dit Bon, allez, là on a un an donc d’ici la prochaine, on va automatiser tout ce qu’on peut et on passera la récolte dans un hamac. Voilà, on est 3 récoltes plus tard et on a toujours pas acheté la Mac. 

– Marc — 20:24 :

 Et est-ce que tu as une opinion à nous partager? 

– Alexandre — 20:26 :

 Oui, alors je trouve que à mesure que le machine learning monte en puissance, on a souvent envie de tout automatiser et donc d’enlever les humains de l’équation. Et ça, je pense que c’est un problème. C’est un problème, déjà parce qu’on rate des opportunités d’avoir quelque chose qui fonctionne mieux. Et on perd aussi le contrôle sur ce qui se passe pour moi, c’est important de laisser le machine learning. À sa place, je dirais donc en tant qu’outil qui est opéré par des humains et sur lesquels on garde le contrôle. 

– Marc — 20:58 :

 Si c’était à refaire, tu changerais quoi si c’était à refaire, alors déjà, il y a eu beaucoup d’opportunités d’apprendre de nos erreurs et d’et de changer les choses. Je pense que je prendrai plus de temps en amont pour penser aux métriques et penser aux produits final et à son utilisation avant de sauter sur la modélisation. La création des modèles, on a vraiment tous une propension à dès qu’on a des données Ben hop, on saute sur la modélisation, on va en faire quelque chose. Mais souvent, ça nous amène à faire des choix qui sont pas les bons à poser des hypothèses sur les métriques qui sont pas du tout les bonnes, et c’est toujours bénéfique de pas céder à cette envie et de prendre le temps de poser les choses proprement. 

– Marc — 21:38 :

 En termes d’infrastructures, aujourd’hui, quand vous devez déployer, quand vous déployez des nouveaux modèles, et cetera, c’est encore l’équipe Data Scientist et cetera qui s’en occupe. Ou est-ce que vous avez mis en place une stack ML Obs que c’est l’équipe Software qui vient vous assister? 

– Alexandre — 21:54 :

 Alors c’est assez automatisé. Donc des déploiements comme je disais tout à l’heure, on peut en faire des dizaines par jour ou nous notre responsabilité, c’est de créer les modèles, de les packager dans un environnement de production et ensuite c’est transmis à l’équipe Software qui eux s’occupent de faire effectivement la mise en prod et les tests plus de type Infra, mais l’intervention manuelle est assez limitée. C’est vraiment surtout du monitoring. 

– Marc — 22:19 :

 D’accord, vous avez bien cloisonné? En fait, l’équipe data, c’est la data science et tout ce qui est gestion de devops et mes logs et compagnie. On laisse ça à l’équipe software oui, 

– Alexandre — 22:29 :

 Dans les grandes lignes. Après, on a un data engineer qui est un petit peu entre les 2. Forcément les frontières sont floues et bougent. Aujourd’hui, l’Inférence Engine, le système de Serving est géré par l’équipe Software. Peut être que demain ce sera à nous, à la faveur d’un recrutement de marinier, les choses bougent à mesure qu’on a de plus d’use case ces nouveaux recrutements. 

– Marc — 22:49 :

 Quels conseils tu donnerais à quelqu’un qui monte une application? Machine learning de 0. 

– Alexandre — 22:53 :

 Mais j’aurais envie de dire que mon commence jamais de 0. Surtout machine learning. Il y a un état de l’art et là, en ce moment c’est l’air des on appelle ça les Foundation models, donc c’est vraiment des outils qui sont très puissants et qui peuvent grandement faciliter des problèmes. Moi, je les vois comme des outils qui permettent de transformer un problème d’image ou d’audio dans un espace où tout devient plus simple. Et donc c’est vraiment important. Avant de se jeter sur le problème, de regarder ce qui se fait, ce qui pourrait être utile. Et parfois voilà, il y a des applications qu’on pensait impossibles ou très lourdes, qui deviennent très faciles. 

– Marc — 23:30 :

 Alors, le futur d’inari, c’est quoi aujourd’hui? 

– Alexandre — 23:32 :

 Alors l’enjeu, pour nous, c’est de vraiment arriver à multiplier les mesures qualités qui sont faites sur tout un ensemble d’espèces, donc du blé, de l’orge, le reste des céréales, du cacao, du café et utiliser des millions de smartphones déployés un peu partout dans le monde pour que, du début à la fin de la filière, tout puisse être tracé et contrôlé. 

– Marc — 23:55 :

 Et Ben Bon courage. 

– Alexandre — 23:56 :

 Merci Alexandre, merci Marc. 

– Alexandre — 23:57 :

 Vous venez d’entendre Alexandre, Annabelle, Head of Data chez Annick. En data-driven One One si vous avez aimé que vous voulez nous soutenir, n’hésitez pas à vous abonner à la chaîne, à liker et à partager à très vite.