Comment industrialiser la production d'algorithmes : la création d'une AI Factory

0:00 Comment scaler une entreprise en intelligence artificielle ? Comment faire évoluer les équipes et la technologie assez rapidement? Comment passer à l'échelle et continuer à améliorer les algorithmes et s'assurer qu'ils sont reproductibles? Comment, comment, comment, comment? C'est Renaud Allioux, cofondateur et CTO de Preligens, qui va répondre à toutes ces questions. Renaud Allioux! Vous êtes monsieur comment, Renaud? Comment ça, exactement? Vous êtes monsieur comment? Vous allez répondre à toutes ces questions. Ah, d'accord. Et après, il y aura une petite session questions-réponses de 10 minutes. OK pour vous? Parfait. Je vous laisse zapper, bouton vert, bouton rouge. OK, super. Ça devrait aller. Bonjour, bonjour à tous. Alors, ça marque. Très bonne présentation, merci. On va vous parler de l'IA, comment on fait, comment on a fait. Et puis on espère que ça vous donnera des infos utiles.

1:04 Donc avant tout, Preligens, qu'est-ce qu'on fait? Juste pour savoir, en général on n'est pas très connu, c'est un peu normal vu ce qu'on fait. On fait de l'IA pour le renseignement et la défense. Donc typiquement, un de nos produits phares, c'est l'analyse d'images satellites. On fait d'autres données et on est là pour rendre le traitement de données plus intelligent, plus rapide et plus sûr. On est malgré tout une entreprise de bonne taille, de 150 personnes. Ce qui est important, c'est que surtout on a une très grosse équipe tech, je vais en revenir, 70 data scientists, 60 développeurs, parisiens et bretons, avec des bureaux commerciaux un peu partout. Pas mal d'anciens des forces chez nous. On est une des plus grosses boîtes d'IA pour le renseignement à la défense dans le monde, à notre sens, enfin nous ce qu'on connaît. Il y a des choses qu'on ne connaît peut-être pas. On est aussi quand même sur Paris une des grosses boîtes d'IA en termes de volume. Ce qui est intéressant, c'est qu'on n'a levé que 23 millions par rapport à d'autres boîtes de notre taille.

2:07 Ce n'est pas qu'on ne veut pas, c'est qu'on fait aussi pas mal de chiffre d'affaires. Donc ça nous permet de scaler aussi sur nos fonds propres. Je vais vous parler rapidement d'IA et en particulier, je vais essayer de tordre le cou à certaines idées reçues. que j'ai pu voir. Et donc, si ça vous dérange, je serais ravi de prendre des questions. Le but étant de solliciter le débat. Donc déjà, le truc que je voudrais dire qui est hyper important, s'il y a un truc à retenir, c'est que l'IA, c'est difficile. C'est vraiment dur. Déjà, les solutions sur étagère ne marchent pas. Alors quand je dis ne marchent pas, ce n'est pas qu'elles ne fonctionnent pas, c'est que si vous espérez résoudre votre problème à plusieurs millions d'euros en allant chercher un YOLO, qui est un des réseaux de détection d'images sur GitHub, et hop, c'est parti. Si ça marche, franchement, super pour vous. En général, c'est plus compliqué que ça. Et en général, ce qui est le plus compliqué, ce n'est pas tellement le réseau lui-même, c'est tout ce qui va autour pour mettre ça en production, mettre ça chez le client, dans son infrastructure.

3:10 Ensuite, ce qui se passe aussi, c'est que pour mettre ça chez le client, pour mettre sur l'infrastructure, il y a pas mal de plateformes de MLOps, pas mal d'infrastructures. Aujourd'hui, comme l'IA est relativement jeune, malheureusement, vous allez devoir redévelopper des trucs. C'est-à-dire qu'il n'y a personne qui redéveloppe son GitHub, il n'y a personne qui redéveloppe sa CI-CD. En IA, toutes les boîtes que je connais, qui en font un petit peu, elles ont des briques qui ressemblent à ça, qu'elles ont redéveloppé eux-mêmes. Même s'il existe de plus en plus de choses. Et tout ça, ensuite, il n'y a pas vraiment de standard pour construire ces équipes. On a tous lu souvent le bouquin de Spotify, les teams, les teams topologie, les trucs là. Donc ça, pour le software, ça fait comme un bout de... tant que ça arrive, et c'est pas pour ça que c'est facile de monter une boîte software, en IA, aujourd'hui, il n'y a pas vraiment de normes, et donc c'est ça qui rend le truc aussi très difficile. Ce qui rend aussi le truc très people intensive, pour une boîte de même taille, même périmètre, si vous avez 10 devs, il vous faut 10 devs, parce que vous faites toujours un software, 10 personnes qui font les outils pour les personnes qui font le deep learning, et 10 personnes pour faire le deep learning.

4:16 Donc nous, on a une équipe de tech, c'est pour ça qu'on a une équipe aussi grosse, c'est qu'en fait, on a une équipe 2 à 3 fois plus grosse, que la même équipe si on faisait pas d'intelligence artificielle. Alors comment on construit une équipe en IA? Comment ça marche? Souvent on va voir ça, on va avoir des boîtes qui vont embaucher des doctorants, des gens qui ont fait Polytechnique et le MVA. Moi j'ai fait ça, mon premier Data Scientist il est de l'ENS et du MVA. Il est encore chez nous, il est super, mais si je devais le refaire, je ne le ferais peut-être pas comme ça. Donc des gens très matheux. Sauf qu'en fait, en vrai, qu'est-ce que fait un data scientist? En vrai, il fait du code. Il fournit du code. Le truc final à la fin, c'est du code. Ça ne veut pas dire qu'il fait du code comme un front, ça ne veut pas dire qu'il faut prendre quelqu'un qui fait du React et lui dire maintenant tu vas faire de l'intelligence artificielle, ce qu'il a aussi déjà fait. Mais de la même manière que... Un développeur qui fait du C++ embarqué, un développeur qui fait du React, un développeur qui fait du .NET, un DevOps, tous ces gens-là, ils ont des métiers différents.

5:23 Ça reste des développeurs. Donc moi, je le dis toujours, et chez nous, tous les data scientists, même dans l'équipe recherche, ils passent les tests de code. Parce qu'en fait, à la fin, ils vont rendre du code. Ça ne veut pas dire qu'ils n'ont pas des compétences, des fois, des thèses en astrophysique ou des masters en maths appliquées, mais ils doivent savoir, et surtout avec le goût un petit peu du code. C'est-à-dire que quelqu'un qui n'aime pas coder, s'il peut faire de l'IA en labo, c'est très bien, mais dans une boîte, il va être un peu perdu. En tout cas, chez nous. Et donc quand vous allez embaucher votre premier data scientist, moi je vous conseille plutôt d'aller chercher quelqu'un de ce qu'on appelle full stack data scientist, quelqu'un qui comprend un peu la computer science, qui sait coder, qui a des bonnes compétences en mathématiques, il n'a pas besoin d'un doctorat, qui sait faire un peu de tout. Parce qu'en fait, l'IA, c'est très transverse. On va devoir comprendre ce que veut le client, faire un peu de maths appliquées, mettre ça en prod. Donc souvent, il faut savoir quand même un petit peu utiliser Docker, voire même de faire de la data exploration.

6:25 Quelqu'un qui a un peu d'expérience et qui est débrouillard. Et en fait, souvent, ces full-stack data scientists, nous, on a un peu de temps. On voit que c'est justement ceux qu'on va mettre aujourd'hui pour faire des expérimentations, pour aller taper des nouveaux projets, plutôt qu'aller directement dans la recherche. Et alors, au fur et à mesure, votre équipe va grandir, vous allez avoir 4, 5, 10 personnes, et puis vous allez voir naturellement, finalement, dans votre team de data scientists, d'IA, d'IA ingénieurs, des gens un petit peu différents, des gens qui sont plutôt bons en code, des gens qui sont plutôt une fibre scientifique, d'autres qui vont avoir une fibre R&D, et vous allez pouvoir commencer à spécialiser. Quand il y a un truc, il a l'intégration à faire, je le donne à lui. Quand il faut vraiment taper un problème de R&D très dur, je le donne à lui. Et donc c'est là où vous allez pouvoir dire maintenant, une fois que je commence à avoir cette équipe, comment je mets en prod. Comment à partir de 5-6 personnes, on peut commencer à mettre des trucs sympas en brotte. Et donc c'est quoi? Aujourd'hui on voit deux modèles pour mettre de l'IA en production. Un qui marche un peu mieux qu'un autre, rien d'étonnant. Comment on prend ces 4-5 personnes et on met ça en prod?

7:30 Et en mettant en prod, des fois c'est sur le cloud, des fois c'est dans une usine quand on fait de la détection de défauts. Nous, on a des caves avec des bunkers, il n'y a pas internet, il n'y a pas de fenêtre, il faut laisser son PC et son ordinateur à l'entrée. Donc comment on fait ça? Ce n'est pas facile. La première version, c'est souvent ce qu'on appelle le lab. Je prends un data scientist, je lui fais coder un Jupyter Notebook. Et là, j'ai une partie d'une équipe infrastructure ou software ou intégration qui va prendre ce Jupyter Notebook et essayer d'en faire un truc qui va faire un truc. Puis il y a la deuxième version de se dire, j'ai une infrastructure, j'ai ma stack, ce qu'on appelle les high stack, j'ai ma stack de MLOps, et j'ai des gens qui vont développer dans ce cadre-là et qui vont mettre en prod. On voit moins maintenant le premier, mais il y a 4-5 ans, quand on a commencé il y a 7 ans, on voyait beaucoup du premier. Franchement, ne faites pas de labo. Je suis désolé s'il y en a qui le font, mais nous ce qu'on voit c'est que ça, ça ne marche pas.

8:32 Et ça en fait, quand on réfléchit, il n'y a personne aujourd'hui où il y a une équipe front, l'équipe front elle développe du front, puis elle envoie l'équipe back, et maintenant démerdez-vous pour que ça tourne. Ça ne marche pas comme ça. Aujourd'hui, tout le monde fait des équipes transverses, tout le monde outil, on a des CICD, on a des choses comme ça. De grand vête, il n'y a aucune raison qu'on ne fasse pas pareil pour l'IA. Et du coup, mon opinion, franchement, ne faites pas un lab. Il faut penser l'IA comme le but, c'est une équipe potentiellement intégrée avec des outils pour mettre un truc en prod. On voit beaucoup de gens qui font de la data science de l'IA, qui n'ont pas accès aux données, qui n'ont pas vraiment d'objectifs ou de KPI clairs. Et c'est quoi le problème à résoudre? Nous, l'avantage, c'est que c'est assez simple. C'est-à-dire qu'on a des gens avec des images satellites qui veulent détecter des avions ou des bateaux dessus. Mais en tout cas, c'est important d'avoir cette approche de squad qu'on a tous. aujourd'hui en software quasiment partout, de la porter quand même sur un parti data science avec un bon outillage.

9:36 Une fois que vous avez fait ça, c'est là où on peut se caler. On rajoute ces équipes, on construit des infrastructures, une plateforme comme en software. Aujourd'hui, c'est vraiment faire des teams plateformes. Nous, on a une team AI Factory qui fait une plateforme d'IA pour les gens dans la boîte. Et donc comment on a construit ça, comment on a construit cette iFactory, comment on a construit cette grosse équipe, qui est aujourd'hui à la pointe, et comment on a construit toutes ces infrastructures d'IA pour que les autres gens travaillent. Donc on a toute une série de nos équipes avec des produits dessus, c'est un vrai produit interne, où en fait, juste pour que d'autres gens puissent travailler. C'est des choses qu'on voit aussi dans le software avec les plateformes, des team plateformes, etc. Déjà, ce qu'on a fait, c'est qu'il faut considérer pourquoi on a besoin de créer ces plateformes, comment on le fait. Déjà, il faut considérer et voir que l'IA, quand on dit une application d'intelligence artificielle, une application... Moi, j'ai souvent tendance à mixer l'intelligence artificielle et le deep learning.

10:40 C'est très mauvais, donc je suis désolé, parce qu'on fait beaucoup de deep. Quand on parle de deep learning, quand on parle de choses comme ça, il faut déjà se sortir de la tête que l'IA, c'est un modèle. L'IA, c'est une application, c'est beaucoup de software avec plein de choses dedans, qui sont packagées, orchestrées entre eux. Donc nous, on va avoir de la data génération, de l'entraînement, de l'inférence, de l'accélération, des modèles de deep learning, de réseaux de neurones, des pré-processing, des post-processing. Tout ça, c'est le package à la fin qui va amener à la production. Et tout ça, il faut l'orchestrer. Donc on prend ces différentes briques, on les orchestre, on joue avec les briques en développement, et une fois que les briques, on est content du résultat, on package tous ces briques dans un docker, comme tout le monde, et on les envoie en prod. Notre live factory, c'est ça, c'est une série de briques et de l'orchestration. Et donc, encore quelque chose auquel je voudrais un peu taire le coup, c'est que l'IA, ce n'est pas juste un modèle, c'est vraiment toute cette partie. Et c'est ça qui est compliqué, c'est-à-dire que trouver un modèle performant sur un problème,

11:43 Franchement, il y a plein de gens qui le font hyper bien, tous les GAFA, tous ces gens-là, ils ont une force de frappe en recherche qui est démentielle. On peut aller chercher leur modèle, les entraîner, les trucs comme ça, et souvent, on peut arriver à des bonnes perfos. Par contre, ce qui va autour, c'est tout ce qui va autour, comment vous intégrez vos données, comment vous intégrez les données clients, comment vous prenez en compte le hardware, c'est ça qui va faire que votre IA va en prendre. Il faut le voir un petit peu comme un process industriel. C'est-à-dire que pour Autria, si vous construisez une voiture, il vous faut toute une série de... De parts, de briques, de composants. Et puis il faut aussi une chaîne d'assemblage pour les assembler. Parce que sinon, si chacun met ses composants de son côté, ça fait n'importe quoi. Si vous avez un data scientist qui utilise du Python, l'autre qui utilise du C++, l'autre qui utilise PyTorch, et il y en a un qui fait TensorFlow, ça vous retrouvez un truc qui ne se cale pas. Et donc si vous voulez votre voiture à la fin, il faut vraiment à la fois les parties, donc toutes ces briques, et puis la ligne d'assemblage. Le problème, c'est que c'est souvent un trade-off à faire.

12:45 C'est-à-dire que souvent, on a des briques très performantes. L'exemple, c'est finalement, vous allez sur GitHub. Sur GitHub, il y a tout. Vous pouvez tout trouver. Et donc vous pouvez avoir les performances, Vous pouvez avoir 100% de performance en allant chercher tout sur GitHub, ou 99%. Sauf qu'en fait, les trucs ne sont pas du tout industriels. Brancher toutes ces briques ensemble, les faire orchestrer, les faire communiquer ensemble, c'est assez compliqué. Et puis à la mer, il y a le truc complètement industriel, où là, vous avez la ligne d'assemblage, ça déroule, vous avez juste à mettre un modèle et des points en prod. Sauf qu'en fait, ça, assez vite, on va être limité en perfos pour des applications complexes. Et donc, sur un graphe, je ne veux pointer personne, mais c'est vraiment une difficulté qui est dure à... C'est très dur de casser ce trade-off, parce que soit vous allez avoir, et c'est le cas de GingFate, c'est une plateforme géniale où on trouve tout, Hugging Face nous permet d'avoir une performance. Il y a beaucoup d'instrumentalisation sur Hugging Face, mais c'est avant tout un énorme repository où on peut trouver tout ce qu'on veut.

13:51 Sauf qu'en fait, après, il y a énormément de travail. Si on veut prendre deux modèles, faire par exemple de l'ensemble in a fait, de la fusion. Si on veut prendre des pré-processings, l'ensemble avec un modèle ResNet derrière, etc. Tout ça, c'est assez complet. A l'inverse, il y a SageMaker, moi j'aime beaucoup faire d'époque avec SageMaker, parce que SageMaker c'est hyper industriel, c'est hyper rapide. On peut prendre un modèle, on fait deux clics boutons, on envoie, c'est une plateforme de ML Ops d'Amazon, et on envoie. Alors je ne veux pas dire... Mais du coup, on se retrouve avec des trucs qui peuvent être assez industriels, mais où en fait il y a peu de flexibilité pour faire des performances très grandes. Et si on va à l'extrême un peu, si on va à l'extrême de la performance, on a des espèces de dragsters. débile, mais en fait le truc il se scale pas, on va avoir des trucs très très simplistes qui se scalent beaucoup. Et nous c'est un peu ce compromis qu'on a essayé de chercher à casser en interne. Alors l'intérêt, pourquoi on a, c'est pas qu'on est spécialement intelligent, pourquoi on a réussi à le casser en interne, et pourquoi c'est difficile pour des gens qui font des plateformes de le casser ce compromis, c'est parce qu'on est un peu spécialisé sur nos use cases. On se diversifie, etc. Mais on a des use cases quand même un petit peu spécialisés.

14:53 Mais du coup, c'est pour ça que des gens, aujourd'hui, c'est ça qui est intéressant, c'est qu'on voit des rapprochements. C'est-à-dire qu'aujourd'hui, avec InFace et Microsoft, se parle pas mal pour justement brancher la plateforme de MLOps de Microsoft à Hugging Face pour qu'en fait, du coup, on se retrouve avec quelque chose qui puisse avoir les deux. Et donc ça, c'est le sujet aujourd'hui de toutes les plateformes. Et c'est pour ça, en fait, que ça fait beaucoup de travail. Soit vous choisissez d'aller chercher des choses sur étagères très performantes, mais du coup, vous allez avoir beaucoup de travail d'instructionnalisation. Soit vous vous mettez fortement sur les plateformes, mais du coup, vous allez avoir beaucoup de travail pour atteindre la perf. Nous, ce qu'on a fait, c'est qu'on a essayé d'avoir quelque chose qui est data agnostic, alors data agnostic sur nos use cases. On fait de l'image, on fait du texte, on fait des choses comme ça. Images, textes, différents types d'images, vidéos. Et on a essayé de construire quelque chose d'assez agnostique pour du deep learning, donc pure deep learning, pour essayer de casser le compromis en interne. Et pour ça, on a construit deux choses.

15:56 On a fait cette orchestration des différentes briques et on a fait des briques. Mais comme on a assez peu de briques à faire, parce qu'on est sur des cas quand même... On n'a pas de... Quand on est en face, il y a un nombre de cas différents qui est... Ça se compte en dizaines de milliers, mais on a quand même des applications, on a pu réduire le champ des possibles, donc on a pu faire un nombre réduit de briques. Aujourd'hui, on a à peu près 120 briques. Et chaque brique, par contre, est complètement customisable. On peut brancher à l'autre assez facilement. Et par contre, à l'intérieur, tout se customise. Et donc, on a un nombre de combinaisons vachement important. Ce qui fait que ça nous permet d'avoir cette industrialisation, puisque toutes les briques sont standardisées. leurs communications sont standardisées. Mais par contre, quand on peut complètement fine-tuner ses briques, ce qui fait qu'on garde de la performance quand même. L'orchestration, on l'a fait avec, j'appelle ça low-code, c'est un peu marketing, c'est des gamelles en fait, on n'a rien inventé. On a des interfaces YAML, ce qui fait que c'est quand même vachement simple, c'est-à-dire que tu as un data scientist qui sort d'école, qui arrive, il a juste à modifier un YAML pour utiliser, nous vraiment des réseaux de neurones, on a dedans des transformeurs, des setformers, des trucs qui sont intégrés par l'équipe recherche.

17:06 Vraiment au top de la pointe de ce qui est fait par l'industrie. Et en fait, il n'y a pas besoin d'être un expert en IA pour intégrer et voir modifier même ces briques-là. Parce que si on demande à un Data Scientist Junior de prendre le GitHub du Secformer ou du dernier Transformer et de le modifier pour en faire quelque chose en prod, franchement, ça va mettre quelques temps. Et ces interfaces qui sont standards, ça nous permet de découpler, d'avoir quelque chose de modulaire, ce qui fait qu'on peut rajouter très facilement des choses. Et ça, c'est ça qui est hyper cool, c'est qu'on a eu beaucoup de temps à faire ça, ça c'est 50 travaux, c'est que maintenant on a une stock quand même assez ouf. Le socle est assez solide. Ce qui veut dire qu'en fait, rajouter une brique, on va dire, je veux traiter un nouveau type de données, je rajoute la brique. Il y a un nouveau modèle qui est sorti, je rajoute la brique. Et ça, ça nous rend quelque chose de franchement performant pour nos cas d'usage. Ça, c'est un exemple de toutes les briques qu'on peut avoir. C'est non exhaustif et puis ça change tout le temps. Mais on a toutes ces différentes étapes que j'avais listées.

18:07 On peut avoir la partie entraînement, la partie inférence, etc. Alors, il y a des trucs qui manquent. C'est juste que nous, on n'a pas besoin de tout. C'est pour ça qu'on arrive à avoir quelque chose d'aussi puissant par rapport à... À deux doigts, c'est que, comme je le dis, on est moins générique, donc on a réussi un petit peu à casser ce compromis. Ça, c'est un exemple justement de nos YAML. Ce qui est intéressant, ce n'est pas le truc YAML, c'est vraiment qu'en fait, dedans, je ne sais pas si on voit, il y a un laser, je crois, là-dessus. Non, il n'y a pas de laser. Si on voit, c'est qu'en fait, on peut vraiment tout modifier. C'est-à-dire que si vous voulez modifier complètement l'architecture du réseau de neurones ici, vous pouvez rajouter du spatial pooling, vous pouvez rajouter différentes options. Par exemple, on avait intégré un module de ce qu'on appelle« squeeze and excitation». Il suffit de l'activer, oui ou non. Ça, c'était 6-8 mois de recherche, l'équipe recherche, qui a ensuite intégré ça dans le framework. Donc en fait, ces petites lignes-là, c'est pas un an de R&D, mais pas loin. Et l'intérêt, c'est que le nouveau, il arrive, il prend ça, il peut activer sa squeeze et l'excitation ou pas, c'est hyper simple. Et il n'y a pas besoin de refaire un an de R&D.

19:11 Quand je parlais de... Ça, c'est logique, quand je disais... Et du coup, avec ce truc-là, on peut orchestrer plein de briques, packager des choses. Une fois qu'on est content des perfos, on met tout dans un Docker, on l'envoie. Ça, c'est par exemple nos... Alors, c'est illisible, mais c'est fait exprès. C'est notre détecteur de navires sur image satellite. Donc, c'est toutes les briques. de dagues où on fait toutes les briques. La donnée arrive en haut, il y a plein de trucs qui se passent, des ensemblings, il y a des trucs vachement simples là-dedans. Quand c'est trop grand, un bateau ça fait pas 3 km de long, donc quand c'est trop lent on enlève. Il y a des choses aussi où on va se dire, ce qui marche bien dans ce qu'on a trouvé, qui marche bien dans la détection de bateaux, c'est de multiplier des résolutions, donc c'est une image à 30 cm de résolution. Il y a une brique qui l'a mis à 30 cm, une brique à 1 m, une brique à 2 m, et puis on mixe à la fin. C'est pour dire, en fait, ce n'est pas un réseau qui va en prod, c'est vraiment tout ce... toutes ces arbres de décision qui, à la fin, et dedans, il y a quelques briques, peut-être une dizaine qui sont des réseaux de deep learning, il y a plein de choses là-dedans, ce n'est pas du deep learning, c'est des choses plus ou moins simples, plus ou moins compliquées, plus ou moins scientifiques.

20:17 Et donc on en revient au fait, quand on dit savoir développer pour un data scientist, c'est que la sortie de notre plateforme et la sortie de nos data scientists, c'est ça, c'est ça qu'ils vont prendre. Donc en fait, il faut quand même, même si on a outillé, même si on a fait le truc, il y a des fois où ça plante, il y a des fois où ça bug, il y a des fois où il y a des cas limites, on ne peut pas faire n'importe quoi avec les fichiers YAML, il faut quand même des gens qui comprennent un peu le code et ce qu'on se goûte de faire du logiciel. Pas faire que les maths. L'intérêt aussi, c'est que ces chaînes nous permettent d'automatiser la mise en production, c'est-à-dire que tout ce package que vous avez vu en avant, c'est construit avec ces fichiers YAML, c'est construit un petit peu automatiquement. Et c'est intéressant parce qu'à la fin, ce gros fichier, ce gros DAC qu'on a vu, c'est en fait un fichier YAML, toujours, avec différentes options. Et puis à la fin, on met ça en production. Quasiment après ce bouton. Donc on a des fois 3 à 4 mois où on va entraîner plein de trucs différents, essayer de combiner des briques ensemble, par exemple avoir entraîné 3 modèles différents qu'on va combiner avec de l'ensemble, après on va mettre différents post-po, une fois qu'on est

21:30 On appuie, on évalue les perfos automatiquement sur différents trucs de test, différentes bases de test, et on envoie ça à la prod, il n'y a plus qu'à prendre le docker et le mettre dans la base militaire. Donc ça, c'est aussi le rôle de notre plateforme, et c'est beaucoup de travail, c'est toujours beaucoup de travail, puisque c'est jamais fini ce genre d'outil. Finalement, en termes de people, pour vous dire, sur les 70 data scientists, on a justement 30 personnes qui utilisent cette plateforme-là. On a 20 personnes qui la construisent et on a 20 personnes en recherche qui vont aller chercher les problèmes un peu compliqués pour essayer de les craquer. Et l'intérêt, c'est qu'on l'a construit comme un projet open source interne. Donc ça veut dire que ce n'est pas que les gens de l'engineering qui développent la plateforme, parce que tout le monde peut travailler dans cette plateforme. Sauf qu'il y a les gens de l'engineering qui sont les gardiens du temple. Donc c'est eux qui vont revoir les PR, c'est eux qui vont faire le design d'archi, etc.

22:32 Mais à la fin, le but, c'est très exact comme un projet open source interne. Donc, quand quelqu'un a une bonne idée, il fait une branche, il rajoute, par exemple, un réseau de neurones dedans, il y a les tests qui passent, il fait l'APR, et puis s'il suit les bonnes normes de code, ça passe et c'est dispo pour tout le monde. Et à la fin, quand même, je vous dis ça, mais à la fin, on ne le fait pas pour le plaisir. Parce que franchement, si je pouvais avoir 5 data scientists, ça me coûterait beaucoup moins cher et ça serait vachement plus simple. C'est que si on a des perfos, On atteint des perfos qui sont quand même assez cool. Si on prend sur la détection d'avion, si on prend quelque chose complètement sur étagère, alors déjà sur étagère, sur la détection d'avion, sur image satellite, de toute façon ça ne marche pas parce que le format ne marche pas. Donc on est obligé quand même de modifier, c'est YOLO SpaceNet, c'est un truc sur étagère, un YOLO modifié pour image satellite. Nous, on a atteint des perfos sur nos bases de tests qui sont autour de 75%. Et puis là, quand on arrive avec à la fin tout ce qui est ensemblé, tout notre package, comme on l'a montré, on atteint des perfos en F1 score qui sont au-dessus de 95%.

23:35 La capacité de reconnaître, donc se dire cet avion-là, c'est un chasseur, la capacité même de l'identifier, c'est-à-dire de dire c'est un MiG-29, c'est un F-16, etc. Et ça, on n'y arrive pas si on prend des modèles sur étagère, ou si on prend même juste des purs modèles qu'on réentraîne, qu'on bidouille et tout, mais qu'on ne paquette pas. Donc ça, c'est pour ça qu'on fait tout ce travail. C'est à la fin pour arriver à ces scores-là. Et aussi parce qu'en fait... C'est ces scores-là qu'on a besoin. Il n'y a pas beaucoup d'applications industrielles où les gens sont OK avec 80%. Aujourd'hui, ça va marcher si on a vraiment des très bonnes perfos, au-dessus de 90, au-dessus de 95 en fonction des use cases. Si on se regresse avec des perfos de 3K ou 80%, ça marche pour des POC, mais ça n'industrielle pas. En termes de comment on fait des images satellites, c'est assez rigolo, donc je vous ai mis quelques visuels. Par exemple, là, c'est de la détection, c'est un truc qu'on a... trouvez marrant, c'est que c'est des images de test, donc en vert c'est les annotations qui ont été faites à la main, et en rouge c'est les détections des algos pour des hélicos.

24:39 Et en fait nos hélicos ont réussi à détecter des trucs que les annotateurs avaient ratés, donc des hélicos qui sont en dessous des nuages qu'on voit. Donc ça pareil, on était assez content qu'on voit ce genre de perfos, donc on commence à avoir des perfos où vraiment On est aussi bien que l'humain qui fait attention. Ça, c'est des choses d'identification d'avion. Donc justement, on est arrivé à identifier... les types d'avions sur un aéroport, ou des trucs qui sont toujours assez impressionnants, c'est la détection de voitures sur une ville, pour aussi vous donner une idée de la complexité, de la valeur que ça peut porter, et de pourquoi je ne suis plus au milieu de la... Désolé. De la valeur aussi que ça peut apporter pour nos clients. On peut aller sur des images comme ça, on peut se retrouver des fois avec 20 000, 40 000, 50 000 véhicules sur une image satellite. Ce n'est même pas une image complète. Et du coup, le but de nos IA, c'est d'arriver à détecter tous ces petits trucs qui sont en fait des voitures, qui font quelques pixels carrés, souvent 10 par 5 ou des choses comme ça. Et donc d'arriver à les détecter.

25:40 C'est pour ça qu'on pousse cet état-là. Merci beaucoup. Et puis, si vous avez des questions, je serai heureux d'y répondre. Merci, Renaud. Passionnant. Passionnant. Quelques petites questions dans la salle? Ah, on va vous amener... Non, non, pour des raisons techniques et tacotiques. On a absolument besoin que vous ayez un micro pour que tout le monde vous entende, parce qu'on est suivis dans le monde entier. Et ce serait dommage de se priver de votre parole, je pense. Donc on va vous amener tout de suite un micro. Il est en train de descendre de manière chaloupée. Il arrive. Merci beaucoup. Oui, il y a une question par rapport à ce qui m'est venu assez rapidement, c'est la question de l'open source. C'est probablement complètement, peut-être idiot, naïf de ma part, mais quel est ton regard sur l'open source dans ta société? D'un point de vue plus général, est-ce que ça fonctionne chez vous?

26:43 Parce que je pense que c'est quand même une... Une politique du secret que vous avez, donc peut-être que ça n'existe pas du tout. Donc voilà, ton avis là-dessus. Alors déjà, on incite pas mal les gens chez nous à faire des contributions open source. On avait des corps d'F qui rasent par exemple, des choses comme ça, donc des gens qui font ça. Il y a beaucoup de débats en interne, justement, on a beaucoup réfléchi à dire est-ce que ça serait intéressant, même pour l'image de marque, de sortir certaines briques de ça. Pour être honnête, le truc qui nous limite aujourd'hui, c'est le temps. C'est-à-dire que je suis persuadé qu'on pourrait, dans notre RIFactory, mettre en open source des choses. Bien entendu, pas tout, parce qu'il y a des trucs à la fois qui sont sensibles, et il y a des trucs qui sont le cœur de notre propriété intellectuelle. Mais en fait, faire ça, ça demande du temps, ça demande aussi... Il y a aussi une question, nos clients, c'est-à-dire que s'ils voient qu'il y a une partie en open source, ils vont nous poser des questions, donc il faut qu'on construise des éléments de langage et tout. Donc, je pense que ça serait intéressant si on avait du temps et qu'on faisait autre chose que la défense. Je pense qu'on l'aurait déjà fait. Là, en fait, on n'a pas eu le temps de...

27:43 Mais je pense que ça serait super intéressant de le faire. Merci beaucoup. Une autre question, s'il vous plaît, ici. Micro arrive. Peut-être qu'on peut le passer, le micro, en fait, je pense. Ça, on se mettra tous au service les uns des autres. Merci pour la présentation, c'était super intéressant. J'avais juste une question sur comment était perçue l'ajout d'une brique. Est-ce que c'est perçu comme étant une verrue? Parce qu'on charge l'ensemble des grilles qui sont mises. Ou est-ce qu'on se dit qu'après, il faudrait peut-être améliorer le modèle et essayer de la retirer? Enfin, voilà, c'est... Alors, pour ça, il faut reprendre en partie des contraintes. C'est-à-dire qu'on a deux types de contraintes. C'est-à-dire que soit on est déployé dans des data centers privés, et là, en général, on ne se met pas trop de contraintes de temps de calcul ou de poids des modèles. Donc on embarque tout ce qu'on peut. Soit des fois on se retrouve avec des...

28:45 Des fois c'est plus contraignant et là on essaye d'être frugal comme tout le monde, c'est-à-dire mettre le moins de briques possible, mettre les réseaux les plus petits, être le plus rapide. Donc en fait ça dépend du use case. Dans le premier cas, franchement des fois il y a des trucs qui sont sur-ingénierés mais ça marche, on s'en fout un peu. Dans le deuxième cas, on essaye là de pruner et de faire hyper gaffe. Merci. J'apprends plein de termes. Pruné, je connais. Pardon. Non, mais c'est bien, j'évolue aussi. Comme les Pokémon, j'ai plusieurs versions. C'est Pikachu, puis demain, ce sera autre chose, je pense. Est-ce qu'on a une autre question dans la salle? Parce que sinon, j'en ai une. En remote. Non? Donc je vais poser ma question. Je la retrouve, je vais essayer de la retrouver vite, Renaud. Alors, c'est une question qui nous vient de Tristan, qu'on salue. Est-ce que vous comptez open sourcer tout ce tooling ML Ops? C'était justement la question dans la salle. On y réfléchit, il y a une question de temps et d'énergie à y mettre, mais je pense que ça ne serait pas une mauvaise idée.

29:52 Sur une partie. J'espère que Tristan est content de la réponse. Est-ce qu'il y a encore cinq bonnes minutes, si vous le voulez, de questions pour... Pour Renaud, juste ici, s'il vous plaît, merci. On a parlé avec ta collègue tout à l'heure qui nous disait que vous n'avez pas accès forcément aux données des militaires. Et on parle beaucoup en ce moment de l'approche data-centrique. C'est-à-dire, pour améliorer les performances, on passe plutôt du temps à travailler sur les données plutôt que sur les modèles. Tandis que vous, vous avez passé énormément de temps, j'ai l'impression, à travailler sur les modèles. Et du coup, est-ce que tu n'es pas un peu frustré par le côté, je n'ai pas accès peut-être aux données qui me permettraient d'avoir de la même performance sans travailler des années sur le modèle? Alors non, on a travaillé un peu sur les données, on travaille aussi un petit peu, c'est aussi une partie de la stack engineering, de la e-factory. Par contre, on a l'avantage, on n'a pas toujours accès aux données finales, c'est-à-dire qu'on va souvent déployer sur des endroits où ils mettent leurs données, on vend du logiciel, on ne vend pas de l'information.

30:56 Donc quand il va poser son logiciel, il va rentrer son flux de données, le client, qui est un flux de données qui n'est pas public. Donc là, le jeu, c'est de trouver des proxys, c'est-à-dire sur image satellite, une image satellite de Airbus, c'est Airbus qui fait les satellites de l'armée française aussi, le satellite civil, finalement, il n'y a pas un écart démentiel entre les deux. Donc en fait, si tu apprends sur des images civiles, ça marche sur des images militaires. Après, par rapport à d'autres cas d'usage, typiquement des cas d'usage qui vont utiliser beaucoup de données scrappées du web, etc., l'intérêt, c'est qu'on a un cas d'usage qui est un peu plus... nos données sont assez propres. C'est-à-dire que souvent, ce qu'on dit dans l'IA, c'est que tu vas passer énormément de temps à avoir des données propres, curer tes données, comme on dit en anglais, désolé d'un nouveau terme. Agrégées. Agrégées, les mettre prêtes pour ton algo. Nous, cette partie-là, on l'a un peu moins. Parce que les données sont quand même des données satellites, elles sont quand même relativement garangées, les données images, etc.

31:58 Ensuite, il y a des fois de la frustration, pour finir sur la question, il y a des fois où on voit des choses où on sent qu'on pourrait faire des trucs démentiels et où les données ne sont pas accessibles, soit des fois elles ne peuvent pas sortir du système. Donc par exemple, tu as des choses sur des bateaux, sur des avions, où la donnée n'est pas faite pour être sortie et passer dans un algo. Et donc tu vois le truc, c'est assez frustrant, tu te dis putain si on pouvait sortir la donnée, la mettre dans un algo, nous on vient dans vos bureaux, on entraîne un algo dessus et ça ferait un truc super, ça c'est un peu de frustration. C'est aussi aujourd'hui, quand tu parles data-centric, tous les nouveaux programmes, par exemple le futur chasseur, les futurs frégates, les futurs sous-marins, tous ces gens-là, maintenant, ils réfléchissent à ça. Ce truc donné, il est dans tous les programmes. Ils savent bien qu'ils vont devoir mettre de l'IA partout, ils savent bien qu'ils vont devoir des fois sortir la donnée, etc. Ce qui n'était pas obligatoirement vrai dans les anciens sous-marins, les anciens bateaux, les anciens avions, les anciens tanks.

33:00 Dès qu'il y a des programmes, les gens pensent à ça. Je pense qu'aussi en 2030, 2035, quand tous ces programmes seront sortis, il y aura aussi un autre moyen de fonctionner et des données plus accessibles, même si elles seront secrètes en termes de confidentialité, mais il y aura au moins le moyen technique pour les récupérer et travailler dessus. Merci beaucoup. Merci Renaud. Y a-t-il une dernière question pour les deux petites minutes qui nous restent? Ah, au premier rang, merci beaucoup. Merci beaucoup pour la présentation. J'avais juste une question, mais c'est presque une demande d'information. C'est quoi votre cycle de release? Combien de temps est-ce que vous mettez pour sortir une nouvelle release? Quelle est la fréquence? Et du coup, au bout de combien de temps, vous avez un feedback du terrain? Alors, les gens vont se moquer de nous ici, surtout s'ils font du WAD. Nous, on avait un cycle de release initialement qui était tous les deux mois. Pour le software, on a un cycle de deux mois et des fois pour les algos, il faut deux cycles pour sortir un algo.

34:04 Là où je vous dis, c'est qu'en fait tous les deux mois pour le software, c'était trop. Donc en fait, nos clients, nous on fait toujours des releases tous les deux mois, mais nos clients maintenant ils vont en une release par an. Honnêtement, c'est la révolution pour eux, sans se mentir. C'est-à-dire qu'il y a les programmes d'armement, jusqu'à assez récemment quand même, les programmes d'armement c'était quand même des cycles en V, tu faisais les spécifications de ton software, il arrivait dix ans après, il ne marchait pas et tout. Au début, quand on est arrivé et qu'on leur a livré des trucs tous les deux mois, ils étaient là. Donc c'est vrai qu'après, quand je dis ça devant des gens qui font du web, où ils mettent en prod trois fois par jour, j'ai l'impression d'être de l'ancien monde. Mais du coup, il y a... Et sur l'IA, en général, il faut... Ça dépend, mais si c'est un nouvel algo, il faut quand même trouver les données, les annoter, les ressortir. Donc des fois, il faut deux mois pour rien pour sortir la donnée, deux mois pour entraîner. Non, souvent, il faut quatre mois pour sortir un nouvel algo. Et les feedbacks, après, on a le site d'A. aller régulièrement chez les clients, on a des réunions de convergence, etc. Je vais vous passer tous les détails, mais c'est aussi très compliqué parce que tous les feedbacks entre le général qui a sa vision, la DGA qui est plutôt la partie programmatique, l'utilisateur qui est derrière le bureau à la fin,

35:18 Et tout ça, ça remonte dans les péripéties étatiques. Et tout ça, ça remonte. Et donc, on a remonté des systèmes pour centraliser les retours, nous pouvoir leur faire des retours, etc. C'est vrai que c'est un cycle agile, mais agile différent de ce que les gens peuvent avoir l'habitude ici. Mais c'est aussi ça qui est marrant. Merci beaucoup. Merci beaucoup Renaud pour cette session. Formidable. Je vous laisse reprendre le micro, je garde Azapet. Azapet, merci beaucoup.