UN ROBOT AGRICULTEUR

– Marc — 00:00 :

 Aujourd’hui, je reçois Arnaud Delaunay, aide of Computer Vision chez Farmwise, en sortant d’école d’ingénieur, Arnaud est idiot et cofondateur de Tizio, entreprise dans la reconnaissance d’images appliquée à la publicité en ligne, il a ensuite travaillé pendant plusieurs années chez l’évalue dans la branche data et machine learning, à construire des produits ML dans plein de secteurs d’activités différentes. Il a ensuite rejoint Pharma il y a bientôt 2 ans et dirige aujourd’hui l’équipe. Machine learning et data Engineering Farmwise. C’est une société qui opère des tracteurs désherbants fondé en 2016 par 2 ingénieurs français en Californie. Il faut une première levée en 2017 construisent 3 machines opérationnelles. 2018 lève une série à en 2019  de 14,5 millions de dollars et pas ainsi construire 14 machines de 3ème génération construit et déployé dans les champs en 2022 Ils viennent de lever une série B de 45000000 de dollars pour se lancer dans la 4ème génération de machines qui sera industrialisée est vendue à travers le monde. Aujourd’hui, c’est une reprise qui représente 70 employés entre les US à et la France. Bonjour Arnaud. 

– Arnaud — 00:53 :

 Bonjour Marc, merci pour l’invitation. 

– Marc — 00:54 :

 Et avec grand plaisir. Alors est ce que tu peux pour commencer nous parler de far away, qu’est-ce que vous faites exactement? 

– Arnaud — 01:00 :

 Ouais, bien sûr, je suis fort Waze. On développé des des machines agricoles intelligentes pour aider l’agriculteur à faire certaines tâches dans les champs. Notre produit principal, il s’appelle Titan. C’est un désherbeur mécanique pour les cultures de légumes. Donc, c’est simple, c’est une machine qui va se déplacer dans les champs de légumes par légumes, j’entends les salades, les tués, les choux, les brocolis et les salariés. Et avec un système de bras robotique à l’intérieur de la machine et de caméras qui vont capter des images des plantes. La machine va se déplacer et les bras vont se déplacer le long de de plusieurs axes et avec des lames situées au bout de ses bras qui vont s’ouvrir à se fermer. Ces lames situées à quelques centimètres sous la surface du sol. La machine va couper les mauvaises herbes tout en préservant les légumes qui sont présents dans le sol et que l’agriculteur cultive. Par mauvaise herbe? En fait, il faut comprendre, c’est toutes les plantes que l’agriculteur n’avait pas prévu de faire pousser dans le champ et elles ont un impact sur le rendement du champ puisque elles vont rentrer en compétition avec les cultures pour récupérer les nutriments du sol, l’eau, le soleil et cetera, et donc à la fin, en fait, nos légumes seront pas aussi gros que vous si on laisse les mauvaises herbes donc voilà la la, la promesse finalement de ces machines, c’est de permettre à nos clients les agriculteurs, de lutter contre les mauvaises herbes sans utiliser de produits chimiques et donc sans avoir recours aussi à une main d’œuvre qui est de plus en plus difficile à trouver. Donc voilà, quelque part, far away se positionne vraiment à la, à la croisée de ces 2 problématiques majeures et souvent méconnues auxquelles est confronté le le monde de l’agriculture, le manque cruel de main d’œuvre. D’une part, c’est de plus en plus compliqué aujourd’hui partout dans le monde, de trouver des gens prêts à les faire. Ces tâches difficiles y a pas mal d’études qui le montrent. Et d’ailleurs, petit aparté, il y a souvent une méconnaissance de la causalité de ce problème là de manque de main-d’œuvre et d’autre part en fait le besoin. La demande qui est faite de réduire l’impact environnemental de l’agriculture. On se rend compte qu’il y a certaines pratiques qui, au nom de la productivité avant, étaient largement adoptées, y a quelques dizaines d’années, et qui c’est des pratiques qui vont avoir les sur le long terme, polluer les nappes phréatiques. Et puis même avoir un impact sur la santé des consommateurs et donc bref, on demande aux agriculteurs de faire plus avec moins, moins de main d’œuvre, moins d’impacts et enfin moins développé des produits pour aider à à répondre à cette immense défi. 

– Marc — 03:12 :

 D’accord et donc ton rôle là-dedans? Et l’équipe qui est en France? 

– Arnaud — 03:17 :

 L’équipe qui est en France, c’est l’équipe machine learning & Data Engineering et notre rôle, c’est de développer des modèles de reconnaissance d’images qui vont tourner en fait à l’intérieur de la machine. Reconnaître les plantes dans les images qui vont être capturées par les caméras qui sont présentes dans la machine. Donc vraiment notre rôle principal, c’est le développement de ces modèles de machine learning, de reconnaissance de plantes. Tout ce qui tourne autour, évidemment, la partie ML Obs, faire en sorte de suivre les performances de ces modèles, suivre la performance des machines dans les champs, vérifier que les opérations se font bien avec la précision nécessaire dans les champs. Résoudre les problèmes s’il y en a, et on va aussi être en charge d’autres parties de la pipeline, de la robotique qui touche à l’image et qui touchent à la à la donnée. On va parler aussi par exemple Dômerie visuelle, odométrie, c’est savoir positionner une machine dans l’espace et visuelle, c’est juste pour dire qu’on utilise l’image pour aussi positionner la machine dans l’espace. 

– Marc — 04:09 :

 Alors chez vous, la data, c’est le carburant hein? Le ces images, donc c’est tout ce qui vous permet de faire vos modèles, comment est-ce que c’est géré? Côté acquisition côté structuration, côté à la fin, consommation. 

– Arnaud — 04:21 :

 Très bonne question, comme je le dis en effet, c’est essentiel, la data pour nous et donc la data principale. La plus importante, ça va vraiment être ces images, capturées par les caméras qui sont présents dans nos machines et cette data. Elle va être générée et consommée en temps réel dans la machine pour prendre la décision en temps réel de couper ou non les plantes qui sont repérées. Donc elle va suivre toute une pipeline à un enchaînement de traitement qui va petit à petit l’enrichir. On va enrichir l’image de la détection des modèles pour savoir où sont les plans dans l’image. Jusqu’à l’activation de ces lames qui pour tuer les mauvaises? Donc ça c’est la première partie. En fait c’est la data acquise et consommée directement en local, en temps réel sur les machines. Cette donnée, on va aussi en extraire une partie et l’envoyer dans notre cloud, hein? On va, on va utiliser les réseaux télécommunication pour pousser cette une partie en tout cas de cette donnée, une partie de ces images là qu’on va stocker en base de données pour pouvoir être utilisé. Je pense qu’on en reparlera, mais ça va surtout permettre de pouvoir mettre à jour et réentraîner les modèles de machine learning. Et puis du coup de cette data récupérer on va avoir plusieurs consommateurs, des consommateurs. En interne dans l’entreprise, mais également nos clients parce qu’il y a un intérêt aussi pour les agriculteurs et après notre action dans les champs de désherbage, de récupérer de l’information autour des champs, donc par exemple, c’est tout bête hein mais mais connaître le nombre de plantes qu’il y a dans le champ, la taille de la distribution, des tailles des plantes, et cetera, c’est de l’information vachement importante pour l’agriculteur et qu’on va pouvoir aussi redonner l’agriculteur. 

– Marc — 05:47 :

 D’accord à posteriori la taille de l’équipe aujourd’hui, ICI JE SOUFFLE COMME UN TYPE QUI S’EMMERDE, PEUX-TU ESSAYER DE VIRER ÇA EN VIRANT LE MOT “AUJOURD’HUI” ? c’est quoi ? 

Arnaud – – : 

 l’équipe à Paris, on est une équipe de 5 ingénieurs, donc on va avoir des ingénieurs. Encore plus, machine learning, machine learning, ingénieurs et des ingénieurs plus data ingénieurs qui vont nous aider sur toute la partie plus ML Obs et traitement de la donnée et des pipelines de données. Donc ça on est, on est 5 à Paris mais on va aussi travailler en étroite collaboration avec des équipes qui sont, elles, basées aux États-Unis, des équipes notamment back end et robotique qui vont contribuer à tout le traitement de ces données, le stockage, l’accès à la donnée de manière efficace et également la consommation de ces données. L’équipe robotique va va utiliser par exemple de la donnée qui va être générée par nos modèles. L’équipe backend va nous accompagner sur tout ce qui est structuration. De l’infrastructure pour que nous machine learning ingénieurs, on puisse avoir accès à cette donnée à postériori de l’action dans les champs pour entraîner les modèles de de machine learning. 

– Marc — 06:41 :

 D’accord, donc, sur les 5 ingénieurs qui sont à Paris, y en a combien qui bossent vraiment sur les algos, combien qui s’occupent de vous donner la bonne data pour bosser sur les algos? 

– Arnaud — 06:51 :

 Ben on, c’est tout simple, on a un d’atteindre Gear 3, machines linéaire dont un stagiaire qui va travailler sur des sujets un peu plus long terme, des sujets un peu plus recherché. Et puis, moi qui dirige l’équipe? 

– Marc — 07:03 :

 Ok alors c’est quoi votre quotidien le le tien par exemple, déjà pour commencer, c’est quoi le ton quotidien chez Fabrice? 

– Arnaud — 07:11 :

 Moi, je vais beaucoup faire le pont parce que c’est pas forcément facile d’avoir une boîte divisée entre la France et les États-Unis, surtout que la côte ouest il y a 9h de décalage horaire donc y a pas mal de de communications à faire et d’être sûr qu’on puisse bien collaborer et échanger les informations entre les équipes ingénieurs et les équipes produits qui sont basés aux États-Unis et nous en France, pour être sûr qu’on aille tous dans la bonne direction. Et après? Bah y a le quotidien de l’équipe, pas que moi, hein, tous les tous les ingénieurs de l’équipe qui va être finalement partagé en 2 dans les responsabilités qu’on a entre la gestion du moment présent, la gestion de la production, de ce qui se passe vraiment tous les jours dans les champs. Et on va dire la gestion plus de du long terme de la RD qui est nécessaire pour toujours être sûr d’avoir des modèles performants, des modèles qui sont précis et qui répondent bien aux besoins. Donc pour être un tout petit peu plus précis, les opérations. On rentre, bah ça va être de résoudre des nouveaux cas, limites qu’on va pouvoir rencontrer dans les champs. 

– Marc — 08:10 :

 C’est quoi un cas limite? On peut donner un exemple, 

– Arnaud — 08:12 :

 Ouais, on peut clairement donner un exemple, ça peut être une nouvelle combinaison d’une plante, d’une type de culture, avec une nouvelle mauvaise herbe par exemple. Bah là le céleri avec les les orties, c’est quelque chose qu’on avait pas où très peu vu avant dans l’acquisition dans le, dans les champs dans lesquels on était allé. On peut par exemple avoir un nouveau client dans une nouvelle région qui va nous mettre face à cette situation là d’une combinaison de mauvaises herbes. Ce qu’on n’a jamais vu et là, forcément, c’est problématique. Il va falloir résoudre ce genre de cas limite et donc ça c’est ce que j’appelle un peu la partie moment présent où il faut être capable d’avoir l’infrastructure et les outils nécessaires pour déjà d’une capter le problème et de 2 savoir le résoudre le plus rapidement possible. Parce qu’en agriculture y a un truc qui est très vrai, c’est qu’on est souvent contraint par le temps. L’action de désherbage, elle doit avoir lieu à un certain moment de la vie de son champ de, de la culture et parfois bah la météo elle va aussi faire des siennes et tu vas pouvoir dire non, c’est pas grave, je reviendrai dans une semaine quand les modèles sont prêts. Ouais, il faut vraiment savoir, être réactif, avoir les outils pour être réactifs. 

– Marc — 09:13 :

 Donc là, dans le cas qu’on vient de dire, OK le céleri, les orties, voilà nouveau nouveau client. Nouveau cas limite si je viens vers vous, il vous dit ça marche pas. Vous avez toutes mes plantes, comment? Comment ça se passe exactement? 

– Arnaud — 09:25 :

 En fait, on va essayer déjà de comprendre si c’est un problème de données ou si c’est un problème autre. La plupart du temps, ça va être un problème de données. Nous, on va essayer de voir déjà si dans les données qu’on avait réussi à récupérer des champs passés, on n’a pas déjà. Chez nous, moyen de venir augmenter, améliorer nos bases de données, nos jeux d’entraînement afin. Bah de d’adapter le modèle, de le réentraîner avec plus d’exemples de ce cas compliqué donc là pareil il faut développer des outils pour réussir à aller faire cette recherche de manière efficace dans nos millions et de d’images qu’on qu’on a déjà collectées, c’est pas forcément une tâche évidente à faire. Et après aussi ça peut être on peut prendre la décision de se dire Bon bah il faudrait qu’on aille à créer plus de données donc on a d’ailleurs développé une machine qui est toute petite, facile à transporter et qui est dédiée en fait à faire de la collecte  de données. D’accord et elle va pouvoir nous permettre au maximum d’anticiper des problèmes, donc notamment sur l’ouverture de nouvelles régions. On va essayer d’aller collecter de la donnée pour évaluer notre capacité à aller déployer nos machines dans les nouvelles. Donc ça dépend des cas. Parfois on a de quoi réagir vite. Il faut évidemment après derrière avoir l’infrastructure pour pouvoir entraîner rapidement les modèles. Être sûr que c’est optimisé et que ça va vite et qu’on est capable de pas avoir à attendre une semaine que les entraînements, tout. 

– Marc — 10:37 :

 Quoi OK donc 2 options qui s’ouvrent? Data Discovery on va chercher dans nos données. Est-ce qu’on n’a pas quelque chose qui ressemble à ce qu’à limite problématique pour essayer de faire en sorte que le modèle s’y habitué un peu plus? Et 2ème option, on refait de l’acquisition de données. Mais là, il va falloir du coup la noter aussi cette donnée. 

– Arnaud — 10:57 :

 Ouais tout à fait. J’allais y venir hein? Dans notre cas d’usage, on est sur de la supervision, hein, c’est on apprend de nos modèles à reconnaître des objets dans des images grâce à de la notation qui a été fait en amont. Donc on a demandé tout simplement à des gens de prendre les images et de dire, voilà ici y a les salades ici, il y a les chénopode qui sont des mauvaises herbes, et cetera, et cetera. Et la qualité de la notation. Elle a un impact direct sur la qualité de ton modèle et donc c’est important déjà dès le début quand on va demander ces annotations là d’avoir un outil qui te permet de contrôler la qualité. Et de capter au plus tôt et au plus proche de l’action d’annotation. S’il y a eu des erreurs, donc nous voilà. On a récemment migré vers un nouvel outil pour les annotations, qui s’appelle kiwi Technology, qui nous offre la possibilité de mettre tout un tas de filets de sécurité autour des annotations qu’on récupère. Et en plus de ça, bah du coup ça c’est aussi un problème auquel on avait été confronté. Évidemment, ce filet de sécurité est parfait, il peut y avoir des erreurs de notation qui traversent le filet de sécurité. Là on se retrouve avec des jeux de données qui ont pas les bonnes annotations et donc si on entraîne un modèle avec les mauvaises annotations, évidemment on a un modèle qui n’est pas performant à la fin. Et ouais, ça nous arrivait récemment où il y avait un cache, je sais plus quel type de plante c’était exactement, je crois, c’était la laitue iceberg où on atteint un espèce de plafond de verre dans la performance de nos modèles. On avait beau chercher, essayer de comprendre ce qui pouvait poser problème dans le design du modèle, dans tous les paramètres qu’on pouvait définir pour l’entraînement, on n’arrive pas à dépasser ce plafond de verre et en fait, en reprenant l’ensemble du jeu de données qui est assez conséquent, on a réussi à développer un outil pour aller automatiquement repérer des potentiels erreurs de notation dans le jeu de données pour les corriger. Et en fait ça, ça a été un Game changer. Et de juste corriger ces erreurs de notation, la réentraîner, le modèle avec les images corrigées et ça a eu beaucoup plus d’impact. C’était beaucoup plus efficace que toute la partie recherche autour du modèle. 

– Marc — 12:40 :

 Quoi non, les données? Les données sont clés et les outils de notation deviennent de plus en plus prépondérants. Vous avez choisi technologie? C’est qui technologie qui vous a permis de faire cette analyse là et donc d’enlever les mauvaises annotations? C’est ça,

Arnaud – —: 

 pas que donc eux vont nous permettre de mettre en place des filets de sécurité dès le début, mais nous on a rajouté quelque chose en plus ou en qui est un peu plus personnalisé et qu’on est un peu plus libre de pouvoir utiliser certains types de modèles. Pour aller détecter ces erreurs de notation dans les images. Donc, on vit en fait en 2ème vague, venir faire un espèce d’audit de nos jeux de données d’entraînement et nos données de test afin de renvoyer ou en tout cas mettre en lumière les images qui ont des problèmes de notation. 

– Marc — 13:16 :

 Ouais tu disais, vous avez migré vers Chili. Vous avez testé d’autres? Vous utilisez quoi avant? 

– Arnaud — 13:21 :

 On utilisait un outil qui avait été développé en interne parce que c’était il y a 4 ans. Je crois qu’on avait commencé à vouloir noter en volume suffisamment grand des images et il y avait eu un tour de marche, un petit benchmark. L’outil existant du marché qui avait été fait et rien ne répondait aux besoins qu’on cherchait. Donc typologie d’annotations un peu particulière qu’on voulait de nos images, il y avait aucun outil qui me permettait et donc bah là pour le coup voilà, c’est l’équipe backend aux États-Unis qui avait implémenté assez rapidement un outil qui a fait son temps. Il nous a largement servi, il nous a largement été utile jusqu’au moment où Ben nous on a aussi complexifié les tâches qu’on donnait au modèle pendant l’apprentissage. On a voulu ajouter plus de détails et on a voulu surtout aussi améliorer la qualité des annotations et donc ça devenait assez lourd de maintenir notre propre outil d’annotation. Et donc c’est pour ça qu après on s’est tourné cet été vers les outils d’annotation. On a fait un autre benchmark et on a choisi qu’il y A la fin qui répondait bien à notre besoin. 

– Marc — 14:11 :

 D’accord et les fonctionnalités qui ont été décisives et c’est quoi sur par exemple, qui dit. 

– Arnaud — 14:17 :

 Déjà l’intégration, on a tout un univers de service, on est dans une architecture assez micro services qui vont échanger les uns avec les autres pour construire nos dataset, nos jeux de données d’entraînement, pour déclencher les entraînements de nos modèles et donc l’outil qu’on avait développé avant en interne. Bah s’intégrer parfaitement parce que bah il avait été créé dans la logique de notre architecture micro services. On avait besoin que l’outil en question puisse s’intégrer facilement, donc il y ait 1SDKA une librairie, une API Python bien faite pour pouvoir l’intégrer facilement dans notre architecture globale. Évidemment que ce soit un outil, une interface utilisateur agréable pour les personnes qui vont à noter et qui soient efficaces dans la notation des mesures de la qualité de la notation, donc par exemple, on peut aller chercher du consensus, on peut aller chercher de la comparaison avec les prédictions du modèle, et évidemment le prix. 

– Marc — 15:05 :

 Qu’est ce qui est le plus important pour toi? Dans une application comme la vôtre? 

– Arnaud — 15:08 :

 C’est une bonne question. Il y a énormément de choses qui sont importantes. Si je devais choisir une chose, ce serait à mon avis la définition de la mesure. De la mesure de performance, hein la la, la métrique, c’est ne pas être seulement data driven mais plutôt métrique driven dans toutes les décisions qu’on va prendre et le suivi de nos performances j’enfonce un peu des portes ouvertes pour les personnes qui travaillent avec des modèles de machine learning ou avec de la data de manière générale. Mais moi je l’ai bien senti dans mon expérience chez Pharma. Ils aiment avant dans mes précédentes boîtes. Si ta mesure est pas bonne, tu vas pas aller dans la bonne direction mais tu vas faire des choix qui vont même t’éloigner de ton objectif final. Ouais l’avantage pour nous, chez Françoise, c’est que c’est concret comme application et donc à la fin, calculer une erreur, c’est compter les Choux-fleurs que t’as tué et les orties que t’as laissé en vie. Ouais donc y a ce côté-là qui est quand même agréable du fait que bah ça parle à tout le monde, c’est pas forcément le pas dans tous les cas d’usage. Dans mes précédentes expériences c’était pas forcément évident d’avoir une mesure aussi concrète, donc dans la tâche de détection d’objets comme on fait dans une image, il y a plein de mesures qui existent pour savoir si ce que le modèle fait est bien ou n’est pas bien donc voilà enfin on peut parler. La précision, hein, le le rappel et cetera. 

– Marc — 16:22 :

 Dans le cadre de votre application, c’est sûr que, à la fin, toute l’équipe, sa performance, c’est facile de savoir combien est-ce que vous avez effectivement tué de Choux-Fleurs, et cetera. Mais si y a l’équipe robotique qui fait quelque chose d’un côté, l’équipe Computer Vision, qui fait autre chose, de l’autre, et cetera à la fin. Finalement, on a une performance collective qui est mesurée dans cette métrique. Comment est-ce que vous gardez vos objectifs, vous, en tant que équipe Computer Vision? 

– Arnaud — 16:46 :

 C’est une très bonne question, c’est important d’avoir la mesure globale du niveau de précision qu’on a dans les champs. Mais aussi de savoir quelle partie va contribuer à cette mesure, à cette évaluation des performances globales. Et donc, il est primordial pour nous. Équipe Computer visuel machine learning de savoir juste la partie détection qui est une seule partie de l’ensemble de la chaîne. Dans quelle mesure elle va contribuer à la performance globale et donc il est clair, comme c’est la porte d’entrée à tout le reste de la plaine, c’est détection bah y a une corrélation très forte entre les performances du modèle image par image et la qualité de du désherbage qui est fait à la fin et donc oui tu essayes de savoir si. Le modèle est assez précis hein? Tout ce qui va détecter, est-ce que c’est vraiment des plantes? Si le rappel est assez haut, est-ce que toutes les plantes qu’on est censés, dans le modèle est capable de la voir tout un tas de mesures qui existent mais y a des choix à faire dans ces mesures, c’est à dire que tu vas essayer de définir aussi qu’est-ce qu’une bonne détection, si l’objet que le modèle détecté est finalement décalé de quelques pixels, est-ce que c’est toujours détecté? Enfin, y a plein de petits paramètres comme ça à décider et à définir. Une autre question, c’est, est-ce que les plantes que je vois partiellement sur les bords de mon image est ce que je suis censé les compter dans ma mesure finale? Et donc on voit bien finalement l’accumulation de toutes ces paramètres là, que la solution, la définition de la mesures et pas si évidente que ça et on peut très vite se retrouver avec une mesure qui reflète pas la performance finale de ton modèle. Et donc t’as une boussole qui indique pas très bien le nord et qui t’amène à faire des décisions et je pense que vraiment le plus important c’est de réussir à s’accorder en tant qu’équipe, mais aussi en tant que boîte, parce que c’est une décision qui est touché. Le produit qui touche les consommateurs. T’as besoin de savoir qu’est-ce qu’on veut faire au final? Quelle est la valeur ajoutée de notre produit pour s’accorder sur cette boussole? Quelle est la mesure qu’on veut optimiser? 

– Marc — 18:23 :

 Et et à la limite. On peut même trouver des facteurs à l’extérieur de l’équipe, c’est à dire qu’il va y avoir peut être la météo ou même le paysan qui essaye de notre espèce ou je ne sais quoi et qui des facteurs qui nous échappent, sur lesquels vous serez jugé aussi à la fin puisqu’on va vous le dire, les dernières ça marchait mieux ou ou ça marchait mieux chez le voisin? Comment vous gérez ces ces externalités au niveau de votre mesure, justement de qualité à la fin? 

– Arnaud — 18:45 :

 À la fin, on veut quand même développer des modèles qui généralisent bien donc, qui sont censés être bons dans plusieurs cas d’usage différents. C’est pas évident, mais on va aussi réussir. À isoler certains champs et à comprendre pourquoi est-ce que la performance du modèle sur tel champ a été bien moins bonne que ce qu’on a en moyenne? Et donc ça on va pouvoir essayer d’aller le récupérer et l’expliquer avec potentiellement certaines externalités, donc ça va être assez du cas par cas. On a aussi développé un truc, on a rien inventé hein? C’est Tesla qui fait la même chose dans son département de véhicule autonome il me semble un système de ce qu’on va appeler des cas d’usage qui vont nous servir un peu d’ailleurs de tests de non régression. Quand on va développer un nouveau modèle c’est essayer d’apporter une granularité supplémentaire à juste. D’avoir le jeu de données entraînement et le jeu de données de tests on va rajouter une granularité supplémentaire dans notre jeu de test en créant des groupements d’images qui représentent un cas d’usage business. Donc je parlais tout à l’heure des combinaisons, plantes, mauvaises herbes, mais ça peut être autre chose, ça peut être en effet le sol qui est un peu humide ou qui va avoir une un aspect particulier, ça va représenter un cas. Enfin y a plein d’exemples et on va créer comme ça ces cas d’usage sur lesquels on va pouvoir sans cesse aussi tester nos modèles et donc quand on a un nouveau modèle qui est prêt, qui par exemple, va corriger un nouveau cas d’usage, donc on aura créé ce nouveau cas d’usage et on va évidemment faire en sorte que le nouveau modèle qu’on veut. Vous voyez est meilleur sur ce cas d’usage là, mais les cas d’usage historiques qui vont nous permettre de contrôler que ce nouveau modèle là qui corrigé le cas d’usage n’a pas régressé n’est pas moins bon sur les autres cas d’usage historique qu’on avait en fait, vous faites un replay les situations précédentes et vous Regardez si le nouveau modèle sur les situations précédentes a pas dégradé ses performances par rapport à l’ancien quoi. 

– Arnaud — 20:22 :

 Tout à fait tout à fait et donc voilà, ça s’ajoute aussi à notre batterie de tests, les tests qu’on va avoir habituellement en développement logiciel un test unitaire, c’est la version. On va avoir un peu ces cas d’usage là. Il y a souvent beaucoup de débats autour de ce que je dois tester quand je fais du machine Learning, bah, ça, ce genre de cas d’usage là qu’on a mis en place, ça fait office de test de non régression qui est un bah une nouvelle flèche à notre arc pour vérifier qu’on va dans le bon sens. 

– Marc — 20:45 :

 Ouais, et alors pour creuser justement ce sujet un peu plus loin, tu prenais l’exemple de la voiture autonome qui est un peu similaire là-dessus. Le problème d’un replay, c’est que les décisions qu’on prend au fur et à mesure avec l’algorithme un pacte futur de l’enregistrement et donc, si on change l’algorithme finalement, on enfin on se teste sur une boucle ouverte quoi, on a que l’algorithme n’a pas d’impact sur la suite des événements? Comment est-ce que vous gérez ça sur le cadre des plantes, en particulier les plantes? 

– Arnaud — 21:13 :

 Nous, c’est un peu différent des véhicules autonomes puisque la détection d’objets qu’on va faire dans les images vont pas impacter la trajectoire du véhicule et là nous ce qu’on cherche à faire, c’est savoir est ce que le modèle de détection plante a bien fonctionné? Les actions qui vont être menées suite aux détections faites par le modèle, on les voit pas apparaître sur l’image parce que les lames vont vont avoir une action derrière le à à l’arrière de la machine donc finalement ces cas-là. On n’est pas tout à fait dans le même cas d’usage que les véhicules autonomes. 

– Marc — 21:42 :

 Vous vous arrêtez à la fameuse métrique intermédiaire dont on parlait tout à l’heure, celle de savoir si vous avez bien détecté la bonne plante au bon endroit

– Arnaud — 21:47 :

 Exactement? 

– Marc — 21:49 :

 Ça, recruter une équipe autour de toi, au moins participer à le faire. Comment est-ce que tu choisis tes computers? Vision Engineers? Qu’est-ce qui est important pour toi quand tu recrutes? 

– Arnaud — 22:00 :

 Y a plusieurs choses évidemment, mais si je devais commencer quelque part, je dirais sa capacité et ses compétences à faire du développement logiciel. Bien tout ce qui est Software Engineering, ça c’est un élément essentiel, surtout quand on développé un produit comme le nôtre et forward qui est un produit qui va être finalement assez complexe, ou plusieurs équipes d’ingénieurs différentes vont travailler et contribuer à cet outil. Là se produit, il faut que tout le monde parle un peu le même langage, les mélangeant les datas, le back end, la robotique et cetera. Donc il faut absolument avoir les bases des bonnes pratiques de développement, maîtriser les outils de de code hein, versioning de de code, être familier avec la CI le tout ce qui va être déploiement, la connaissance des outils de test. Les concepts clés de développement, et cetera, et cetera. Donc ça ça. Je le mettrai en un en fait en 2, je dirais le côté un peu ingénieur d’avoir une capacité à résoudre des problèmes, donc déjà à poser le problème à définir et mettre les hypothèses de façon claire parce que nous c’est notre quotidien, résoudre des problèmes qu’on n’avait pas forcément anticipé et donc après bah savoir prioriser l’exploration, choisir d’implémenter une telle ou telle solution, mais dans quel les tester quoi et enfin évidemment bah je dirais les, les connaissances théoriques en Computer vision, en machine learning, ou du moins ça fait sa capacité à comprendre. Comment la chose fonctionne donc voilà, je vais chercher un développeur, un ingénieur, un mathématicien, enfin une développeuse, une ingénieur et ou une mathématicienne. Voilà. 

– Marc — 23:22 :

 Ok chez vous, vous avez donc un poste tournant, que vous appelez “on Call” hein? D’astreinte si on si on parle français, ingénieur d’astreinte en gros Computer Vision, ingénieur Uncle, en quoi ça consiste? En gros, parce qu’on a du mal à imaginer quelle urgence on va avoir à résoudre concrètement à l’échelle de quelques heures comme ça, de pour être réveillé la nuit pour aller résoudre, hein, un problème alors bon y a 9h de décalage horaire donc c’est on arrive bien l’imaginer mais concrètement qu’est ce qui va faire l’ingénieur d’astreinte s’il est appelé en? 

– Arnaud — 23:54 :

 Urgence, oui. Alors c’est vrai, c’est pas forcément un concept qu’on a partout, nous on est une jeune entreprise hein, une petite boîte, un système qu’on a développé au cours des années. Donc il peut y avoir en effet comme tu le dis encore quelques problèmes qui apparaissent dans les champs et qu’il va falloir régler ce qu’on a pas dit, c’est que falaise, on est aujourd’hui sur un système de service, c’est à dire qu’on a des propres opérateurs qui vont dans les champs opérer les machines. Et les agriculteurs, en fait, payent notre passage à l’hectare. La nouvelle génération de machines et la série B d’ailleurs, va nous permettre de migrer vers un système hybride à la fois de service et de vente de machines. Parenthèse fermée donc, nos opérateurs peuvent faire face à des problèmes dans les champs et donc nous on va en tant qu ingénieur d’astreinte juste devoir être là pour conseiller, assister les opérateurs quand ça arrive sur la meilleure décision à prendre. L’avantage dès 9h00 de décalage, c’est qu’eux, quand ils commencent à à les champs le matin en Californie, il est 15h 16h en France. Et souvent, les problèmes quand ils arrivent au tout début du champ. Oui, donc on n’est pas réveil au milieu de la nuit, mais notre objectif en tant qu’astreinte, ça va de les guider sur potentiellement un changement de modèle ou en tout cas sur la qualité de l’image. On peut leur dire mais c’est pas normal d’avoir cette image là, y a peut-être un problème avec la caméra, est-ce que tu peux pas vérifier s’il y a pas un peu d’eau derrière là? Lentille des choses un peu bêtes comme ça autour du modèle, mais après on peut aller jusqu’à même potentiellement leur demander de changer de modèle si par hasard on travaille en ce moment sur l’amélioration d’un modèle qu’on avait pas encore déployé, ça peut être le moment si jamais. C’est vraiment la seule solution, ça peut être le moment de déployer un peu en urgence un modèle pour permettre aux opérateurs de finir le champ. 

– Marc — 25:27 :

 D’accord, éventuellement un rollback sur un modèle précédent aussi. 

– Arnaud — 25:31 :

 Ou un rollback exactement, mais ça peut être aussi inversement. Un modèle qu’on a déployé qui pour une raison pour une autre, avait un problème qu’on avait anticipé et donc on va évidemment faire un rollback. L’objectif de la nouvelle génération de machines, hein, qui va être destiné à la vente. Là, l’objectif c’est de plus avoir aucun problème ou en tout cas que les problèmes puissent être traités directement par l’agriculteur qui posera la machine. 

– Marc — 25:51 :

 D’accord, est-ce que tu as une anecdote ou une opinion à nous partager data? 

– Arnaud — 25:55 :

 Ouais, je pense que c’est assez important de parler data et que tout le monde dans la boîte puisse parler et comprendre, donner, parler et comprendre. Mesure métrique, la data, c’est un outil qui est réservé aux data Scientist, au pôle Data de la boîte. Il faut vraiment développer cette culture à l’échelle de la boîte et donc ouais, la petite anecdote que je voulais partager à ce sujet, c’est quelque chose dont on s’est rendu compte il y a pas si longtemps, on est allé rendre visite à nos équipes opérationnelles dans le but bah de voir avec eux comment est-ce qu’ils percevaient la mise à jour, le déploiement de nouveaux modèles. L’impact qu’il avait sur les opérations avoir un peu leur ressenti terrain et on leur a posé une question toute simple, c’est, comment est-ce que vous vous décidez si oui ou non, on peut désherber un champ et là, on est allé rendre visite à nos équipes opérationnelles ils nous ont répondu, Ah bah c’est pas compliqué, on commence à comprendre un peu comment vos modèles de machine learning fonctionnent et donc bah on sait dire si ça va marcher avant même d’aller dans le champ et par exemple il nous disait Bah là je sais que l’agriculteur a fait tel type d’opération juste avant nous, donc par exemple ça peut être appliqué à un fertilisant et qui va avoir un impact sur les laitues et voilà, on sait que les modèles vont peut être moins bien fonctionner donc on va décider de pas aller faire ce champ et là en fait, on s’est rendu compte qu’y avait un problème parce que nous on connaissait ce cas limite et on avait travaillé dessus. On avait déployé un nouveau modèle qui est réglé. Ce cas limite dont il parlait, mais l’information avait été mal communiquée et donc les opérateurs étaient pas forcément au courant du déploiement de ces modèles et du fait qu’on avait corrigé le problème et donc on se retrouvait à avoir un impact business sur le fait que la data était méconnue. La mesure de performance était méconnue au niveau des opérateurs et il y avait un vrai problème de communication. On était responsable, hein? C’est à nous aussi de faire en sorte de rendre cette mesure, cette data intelligible et de la partager et de la communiquer à tous les niveaux de la boîte et que les décisions qui soient prises à tous les niveaux puissent être basées sur de la data et pas seulement sur des intuitions qu’il a étaient des bonnes intuitions, mais caduques. 

– Marc — 27:43 :

 Oui, vous aviez pas anticipé, vous, en tant qu’ingénieur qui créé l’algo que les gens allaient en fait s’adapter aux caractéristiques de votre algo, aux limites et finalement quelque chose qui aurait pu être réglé à 100 % Tout simplement en communiquant. 

– Arnaud — 27:56 :

 Ouais, voilà tout à fait, oui. L’algo est là au service de l’application et là on s’est retrouvé dans le cas opposé où finalement l’application était au service des limites de la loi alors que nous, notre objectif c’est que dès qu’il y a un problème, c’est de pouvoir le résoudre afin que ce soit plus un problème et qu’on puisse désherber plus possible de cas d’usage différent dans les champs. 

– Marc — 28:15 :

 Vous avez d’autres usagés? De la data en particulier, peut-être pour prendre des décisions business, et cetera, qui ne soient pas justement cette data image dont on parle depuis le début de ce podcast? Ce que vous vous faites comme usage autre? 

– Arnaud — 28:29 :

 Ouais tout à fait. Bah y a toute une donnée business, on va dire qui est importante du nombre de de champs qu’on va faire la vitesse à laquelle on est capable aussi de traiter les champs, les types de culture. Donc oui, il y a beaucoup de décisions business qui sont prises dans la boîte grâce à la donnée. Je suis pas forcément moi personnellement mieux placé pour en parler, mais je sais par exemple qu’au tout début de falaise, il a bien fallu commencer par quelque part et on pouvait pas du jour au lendemain dire on va faire tous les légumes et on va envoyer nos machines dans les il a fallu choisir un premier type de culture dans lequel on pouvait envoyer les machines. Et ensuite prioriser les plantes qu’on allait supporter et donc la data qu’on avait utilisée à l’époque juste pour la petite anecdote, hein. Une donnée publique qui nous a permis de guider notre prise de décision. On a récupéré la donnée du ministère de l’Agriculture américaine, des rapports régionaux de la Californie, en l’occurrence sur la surface occupée par les différentes cultures. On a échangé aussi avec les principaux acteurs du marché à Salinas, Hein, c’est la région maraîchère qui est au sud de la baie de San Francisco. Et en fait, on s’est rendu compte que le légume numéro un en termes d’hectares, c’était la laitue et que tout le monde sans exception avait au moins un champ de l’UE. Et donc voilà, c’est un exemple tout bête de base sur la data, on a pris une décision business de commencer par là laitue. 

– Marc — 29:33 :

 De data public. 

– Arnaud — 29:34 :

 La data publique en l’occurrence. Ouais. 

– Marc — 29:36 :

 Alors comment gérez vous le lien avec les opérationnels qui manipulent les machines chez vous? 

– Arnaud — 29:41 :

 C’est un lien super important parce que c’est un lien bilatéral. Si je peux utiliser ce terme, ça va dans les 2 sens, hein? On va avoir besoin d’eux pour remonter les problèmes rencontrés dans les champs. Donc nous, on va mettre en place plein d’outils de monitoring et de suivi des performances. On va faire remonter des données de la machine pour savoir potentiellement ce qui a marché, ce qui a moins bien marché, mais on a besoin aussi des opérateurs sur les champs pour nous remonter les problèmes rencontrés et les caractériser un peu plus. Ils peuvent nous expliquer tout ce qui peut avoir eu lieu autour de notre action dans le champ et qui pourrait expliquer la mauvaise performance là des modèles par exemple. Donc on a besoin de communiquer 2 à nous pour collecter ces problèmes afin de mieux les comprendre et pouvoir les résoudre le plus efficacement possible et inversement. Bah nous, on va communiquer sur les nouveautés sur les déploiements de nouveaux modèles, les cas d’usage qu’on est capable de traiter les nouveaux cas d’usage sur lesquels on travaille encore. Donc c’est vraiment un lien qui va dans les 2 sens. Eux, c’est notre lien direct avec les champs et les agriculteurs, et nous on a besoin de les tenir informés de ce sur quoi on travaille et des cas qu’on débloque entre guillemets pour qu’eux puissent prendre la décision d’aller. Pas dans le champ et finalement aussi, hein. On a plusieurs outils pour cette communication, là, on va avoir un outil interne qui s’appelle le Dashboard, qui va centraliser toutes les infos de tout ce qui se passe avec les machines, mais un outil comme slack de communication est super important pour pouvoir échanger de manière indirecte avec les opérateurs. 

– Marc — 31:01 :

 En tant qu’on parle d’outils, est-ce que tu peux nous donner un peu le panel d’outils que vous utilisez? Toute la stack technique, on va dire en 2 secondes hein, ça rentre dans le détail que vous avez choisi comme outil on va avoir en fait un mix d’outils du marché et d’outils maison. On va avoir une grande partie dans le cloud, dans notre club. Trailer c’est WS Mais après quelques petits outils qui vont nous aider au quotidien par exemple, c’est du marché, on va parler de White and basses. C’est pour IB en français, c’est un outil de suivi des expérimentations qu’on peut faire en entraînement de modèles de machine learning. Ça c’est super important. 

– Marc — 31:30 :

 Spécialisé pour le Deep learning il me semble hein? 

– Arnaud — 31:32 :

 Spécialisé pour le deal, c’est que je l’utilise que dans des cas d’usage de Deep learning, mais c’est super important, surtout avec une équipe qui a doublé en taille depuis que j’ai rejoint par exemple ou le nombre d’expérimentations va exploser et on va avoir besoin de suivre un peu les ce qu’on a fait et quels étaient les résultats. Bon, un autre exemple d’outils, c’est Red Dash. Je connais pas. Avant de rejoindre Waze qui est un espèce de méta base, hein, qui nous permet directement de faire de la visualisation autour de nos de nos données présentes dans les bases de données. Et puis après tout un tas d’outils internes qu’on va développer dans un outil de modèle Registry, hein, de d’être capable de savoir quel modèle ont été entraînés et si je peux les déployer ou pas. Voilà. 

– Marc — 32:03 :

 C’est quoi l’outil que t’aimerais avec pas? 

– Arnaud — 32:05 :

 Je pense qu’il faut bien choisir ses outils et pas forcément se précipiter sur le premier outil à la mode tant que tes outils répondent aux besoins à tes besoins et donc là pour répondre à ta question, je pense y a plein d’autres outils qui pourraient nous aider à faire mieux par rapport aux outils qu’on utilise, mais peut être un problème qu’on commence à avoir et pour lequel on a pas trop d’outils, c’est celui d’avoir une vue globale de toutes les opérations autour des modèles, donc toute la partie MLops suivre un peu l’orchestration des tâches qui vont avoir lieu en dehors de la machine, donc la récupération des données, la création des dataset, le déclenchement des entraînements de nos modèles de machine learning. On a plein de services qui vont gérer différentes parties de toutes ces tâches là, mais on n’a pas un orchestrateur central pour avoir la vue globale et donc peut être qu’un air flow ou un prefect. Il serait bienvenu pour répondre à ce besoin. 

– Marc — 32:55 :

 D’accord, si c’était à refaire, tu changerais quoi et si tu avais un conseil à donner pour ceux qui veulent se lancer là-dedans, monter une boîte, mettre une place, une infra data? SOUFFLE

– Arnaud — 33:07 :

 Cette question est pas facile, mais au risque de me répéter, je vais dire que le plus important, c’est vraiment de la définition de cette mesure qui va être en phare et qui va guider tes décisions et donc si c’était à refaire chez Farmwise, peut-être que j’y aurais passé plus de temps au début et ça nous aurait potentiellement à éviter aussi. Quelques décisions qui étaient les bonnes et donc vraiment se concentrer sur l’implémentation de cette mesure. Enfin, la définition, déjà, l’implémentation ensuite pour être sûr que tu tu as une métrique qui correspond à la valeur que tu cherches à porter au final dans ton produit. Donc ouais vraiment sur un produit basé essentiellement sur du machine learning, c’est la clé. Donc voilà j’enfonce peut-être une porte ouverte mais comme toutes les décisions stratégiques. Et toi tes choix techniques vont se baser sur cette mesure là, il faut prendre le temps de bien là définir. 

– Marc — 33:52 :

 Ok alors pour conclure. Le futur de firmware c’est quoi ouais, 

– Arnaud — 33:57 :

 Alors, le futur de firmware c’est la 4ème génération de machines hein? Aujourd’hui, la douzaine de machines qu’on a qui tombe dans les champs, c’est la 3ème génération. Demain, c’est cette 4ème génération là. Bah le but, ça va être de vendre ces machines, on va passer d’un système de service à un système hybride, on va continuer à faire du service avec cette nouvelle génération mais surtout on va pouvoir vendre des machines à travers le monde et Ben là il faut être encore plus précis, avoir des machines fiables et que ce soit aussi facile à utiliser. Pour les agriculteurs que n’importe quelle autre type de tracteur qui utilisent les champs. Donc bah ça c’est le gros enjeu de 2023 ça va être la vente de ces premières machines là et faire en sorte qu’elle soit le plus robuste et les plus précises possible. 

– Marc — 34:35 :

 C’est plutôt un challenge pour l’équipe produit, on va dire Interface utilisateur et compagnie, j’imagine. 

– Arnaud — 34:40 :

 Oui, beaucoup, mais nous également. Il va falloir aussi que nos modèles généralisent bien et là où il y avait beaucoup de communication et d’allers retours avec nos opérateurs. Là y en aura beaucoup moins, donc il va falloir faire en sorte de gérer aussi. Beaucoup plus de data j’aurai beaucoup plus de cas d’usage et avoir des modèles fiables et performants. 

– Arnaud — 35:00 :

 Super merci Arnaud, merci Marc. Vous venez d’entendre Arnaud Delaunay sur data driven One One, merci d’avoir écouté si vous avez aimé et que vous voulez nous soutenir, n’hésitez pas à vous abonner à la chaîne, à liker et à partager.