Exotec : Une reine et une armée de robots

Bruno — Pour beaucoup de devs, dans le monde du web ou du soft, l'approche microservice est relativement bien acquise. Plutôt que d'avoir une seule code base qui fait tout, nous avons plusieurs petits projets où chacun un objectif précis et tout le monde communique avec l'ensemble via des API. Dans le monde animal, l'approche minimaliste est tout autre. Chaque fourmi a les mêmes capacités que ses congénères, bien que simple, et elle ne communique que de proche en proche. Et pourtant l'ensemble fonctionne à merveille. Certains domaines de la robotique tendent à suivre ce second modèle. Mais alors, comment créer un robot simple où la complexité est dans la collectivité ? Une reine est-elle aussi nécessaire ? Et surtout, pour innover dans ce domaine, faut-il toujours mettre un coup de pied dans la fourmilière ? Pour répondre à ces questions d'orchestration, je ne reçois pas Stanislas Lefort, mais elle s'y connaît en direction Sophie. Bonjour.

Sophie — Bonjour Bruno.

Bruno — Alors Sophie, est-ce que tu pourrais te présenter pour les gens qui ne te connaîtraient peut-être pas ?

Sophie — Eh bien, je suis Sophie et je travaille chez Exotec, une entreprise de robotique qui fournit des robots pour la logistique, qui les conçoit, qui les design, qui les fabrique en France. Et qui les déploie partout dans le monde.

Bruno — Alors, ce domaine de la robotique, moi, je trouve forcément passionnant. Je pense que chez beaucoup de devs, il y a une espèce de fascination. C'est un peu ce que tu disais au début du live. Il y a le fait de faire bouger quelque chose, en fait. Je ne sais pas si aussi qu'on est tous passionnés de SF, qu'on a tous eu une passion en voyant Terminator ou je ne sais quoi, mais le fait de toucher à un robot, pour moi, il y a quelque chose d'encore plus magique que de créer une app.

Sophie — Oui, alors là, je te rejoins complètement. Moi, j'ai fait le choix du développement industriel justement pour ça, pour voir les choses bouger et puis se dire, finalement, quand tu fais une app, tu ne verras jamais l'utilisateur final utiliser ton app. Donc, tu ne verras pas comment il l'utilise. Alors que dans l'industriel, tu vois l'utilisateur final où tu vois les choses bouger, le robot, le convoyage, etc. Et tu vois, si tu t'es planté, ça se voit directement. Ça a des impacts un peu plus gros que juste ton app qui s'est plantée et ton utilisateur qui ne peut pas accéder à un service.

Bruno — Ce qui nous amènerait à plein de questions effectivement sur comment tu débugs ce genre de choses sans péter 22 robots pour voir ce qui se passe. Du coup, alors de moi, ce que j'ai compris d'ExoTech, donc c'est une solution avec un ensemble de robots dans un entrepôt pour déplacer un ensemble de paquets. Donc on a plein d'images qu'on a pu voir dans différents entrepôts, que ce soit ExoTech ou d'autres. On voit ces robots qui vont à toute vitesse dans les entrepôts. Avant de plonger sur différents aspects techniques, est-ce que tu peux nous expliquer un petit peu les différents types de robots, comment est-ce que tout ça s'agence et ça se construit ?

Sophie — Alors, à l'origine, Exotech, c'est la solution du robot Skypod. C'est des petits robots qui font à peu près, je crois, 60 par 60, un peu comme des gros robots aspirateurs qu'on verrait à nos domiciles. Et donc, ces robots, ils viennent dans un entrepôt, ils sont capables de se déplacer au sol et de grimper jusqu'à 12 mètres de haut pour aller chercher des bacs qui contiennent des articles pour faire de la préparation de commandes. Donc on est vraiment dans un domaine logistique. Et on vient équiper des entrepôts qui, auparavant, n'étaient pas équipés en solutions. Alors, soit avec des solutions d'automatisme un peu plus à l'ancienne, soit carrément des gens qui poussent des caddies avec une petite liste de courses à côté. Voilà, donc on a ces robots-là. Et puis après, on a d'autres robots. On a des bras robotisés qui viennent en complément, en fait. Donc, le robot Skypod vient sous le robot Skypeaker qui vient récupérer l'article dans le bac qu'il vient lui présenter le robot. et il va le déposer dans le bac qui va faire la commande pour le client final. Et on a aussi une solution de convoyage automatique. Donc les convoyages, c'est ce qu'on va voir par exemple, je ne sais pas moi, dans les aéroports, vous savez, les rouleaux qui transportent les différents bagages. Donc on a depuis cette année commercialisé une solution de convoyage intelligente.

Bruno — Avec un système d'aiguillage, c'est ça ?

Sophie — Avec des systèmes d'aiguillage et surtout, c'est du convoyage intelligent parce qu'il est capable de savoir à tout moment où est, Et ça, c'est assez nouveau dans le domaine, en fait. Donc, la charge, elle est suivie en permanence. Et puis, ça va l'aiguiller. Dans un entrepôt total, on va avoir un robot. Alors, on va s'interfacer avec des robots qui ne sont pas fournis par nous. Par exemple, tu vas avoir un robot au début. Tu as une palette qui arrive avec des colis. Donc, tu vas avoir un robot qui va te dépalétiser. Donc, ça, c'est des gros bras robotiques qui viennent prendre le colis et puis le poser justement sur le convoyage. Et puis ensuite, le colis, l'aiguillé vers des tunnels RFID, par exemple, pour savoir ce qu'il y a à l'intérieur, des balances, etc. Jusqu'à être amené dans notre système, pris par les robots et ensuite emmené, stocké dans un oracle. Et quand il y en a besoin, ensuite, c'est récupéré. Alors, il y a plein de choses. Ça peut être des colis pour ensuite faire de la préparation de commandes. Par exemple, tu vas avoir le colis qui contient, je n'en sais rien moi, le dernier Harry Potter, c'est un petit peu vieux, qui contient un ensemble de chaussettes, par exemple. Et puis, toi, tu as commandé une paire de chaussettes chez Decathlon en ligne. Et donc, ça va aller chercher ta paire de chaussettes. Et ensuite, le robot va amener le bac qui contient l'ensemble des chaussettes. Et puis, il y a un opérateur qui va prendre la paire de chaussettes et la mettre dans ton colis. Et ce colis ensuite, lui aussi il est convoyé ensuite pour aller en général vers une machine qui va fermer les colis, une machine qui va coller une étiquette une machine qui va l'emmener au bon endroit pour être ensuite, amené jusque dans ton magasin ou jusque chez toi Alors attends.

Bruno — Il y a plein de trucs que j'ai envie de creuser je vais commencer par quoi, je vais commencer par le nom de la chaussette qui est peut-être le plus anodin, parce que du coup c'est à dire qu'il faut que tu as un système qui soit capable, d'apporter l'ensemble du entre guillemets du stock de chaussettes pour que t'aies un opérateur qui prenne qu'une seule paire oui mais du coup pas forcément.

Sophie — L'ensemble du stock mais en tout cas un carton.

Bruno — Qui contient ou un bac qui contient l'ensemble.

Sophie — Une partie de chaussettes.

Bruno — Parce que du coup, Tu vois, il y a le ratio de se dire, est-ce qu'on conçoit un robot qui va être capable de trouver la paire de chaussettes dans l'ensemble versus un robot qui a une capacité à transporter un paquet entier de chaussettes ? Alors peut-être que les chaussettes ne sont pas très lourdes, mais du coup, ça augmente quand même les capacités de ton robot. Est-ce qu'il y a eu cette espèce d'arbitrage qui a dû être fait chez Exotec en disant, est-ce qu'on prend plutôt un truc qui va être capable de prendre un produit ou qui est capable d'amener l'ensemble pour qu'un opérateur choisisse ?

Sophie — Alors, c'est très compliqué de prendre un produit en particulier et d'être un robot standard. Parce que tu veux prendre une paire de chaussettes, ou tu veux prendre une bouteille d'huile, ou tu veux prendre un paquet d'œufs. Un paquet d'œufs, ça ne va pas être le même type de préhension. Il y a certains trucs que tu ne peux pas les prendre. Surtout que si tu veux un robot qui est capable de prendre justement un objet en particulier, ça veut dire qu'il est capable. Tu as de la vision, tu as du machine learning pour être capable de dire, ok, c'est bien un article, il est positionné dans ce sens-là. Pour le prendre il faut que je le fasse comme ça voilà donc c'est ce que fait notre robot justement Skypicker on va être capable assez facilement de prendre des boîtes par exemple tu veux prendre des dans la parapharmacie des boîtes, C'est facile, c'est du carton, c'est un pavé, donc ça, c'est assez simple. Mais par contre, dès que ça commence à devenir transparent, dès que ça commence à être emboîté, dès que ça commence à être mou, on va dire comme des habits, il faut des préhenseurs différents. Tu ne peux pas le faire avec une ventouse ou il faut quelque chose qui pince, etc. Et tu ne peux pas adapter en fonction du produit, changer de préhenseur facilement.

Bruno — Et en même temps, parce que tu disais tout à l'heure que vous avez des robots qui ont une capacité à monter à 12 mètres de haut. Alors ça, je ne m'en souvenais pas dans la préparation, parce que 12 mètres, c'est quand même beaucoup. c'est très haut, s'il faut sortir un carton entier même d'œuf ça peut être assez léger mais tu vois si t'as je sais pas combien deux dans l'ensemble, à 12 mètres de haut faut quand même un robot qui a un certain équilibre une certaine résistance, ça te rajoute quand même aussi une complexité assez forte.

Sophie — Je pense que ce qui a été décidé au début c'est de remplacer, de remplacer la partie pénible du travail humain de la préparation de commandes, c'est à dire le gars qui se balade avec son caddie et en réalité c'est pas une liste de course manuelle ils ont une voie automatique enfin une voie robotisée pas très agréable dans un casque qui leur dit allez à l'aller numéro temps etc prendre ça dans l'étagère numéro temps t'en prends 3 t'en prends 4 ils mettent ça dans un dans un gros caddie et puis après ensuite ils vont redispatcher par commande ce genre de choses, Ça, ça s'appelle du man-to-goods, c'est-à-dire l'homme va vers les articles. Et nous, on fait du good to man, du good to person, c'est-à-dire le robot amène à l'opérateur les articles, justement, les références. Mais par contre, on a encore besoin de l'opérateur pour choisir, prendre le bon nombre d'articles, etc. Et amener un carton, un carton que ce soit des cartons d'œufs, que ce soit des cartons de chaussettes, que ce soit des cartons de bouteilles, ou quoi que ce soit, ça reste un carton, donc tu n'as pas besoin de designer des robots différents. Par contre, choisir effectivement, ça devient complètement différent, être capable de savoir combien tu en as pris, ça c'est compliqué. Et donc le choix, ça a été de faire un robot qui est petit, qui est compact, qui est très bas. Je ne sais pas, en hauteur, il fait une dizaine de centimètres, une quinzaine de centimètres de haut, pas plus. Du coup, tu as un centre de gravité qui est très bas. Et donc tu peux monter en fait pour monter ce qu'il fait c'est qu'il sort des espèces de, crochets on va dire qui se mettent sur des crémaillères et avec les crémaillères il monte mais en restant toujours horizontal et une fois qu'il est à la hauteur voulue il sort une fourche pour aller chercher le bac qui l'intéresse, et ensuite il redescend mais il est toujours stabilisé parce qu'en fait il est accroché au rack il est accroché aux étagères.

Bruno — J'ai dû trop lire Spirou quand j'étais petit parce que moi j'imaginais des espèces de jambes qui.

Sophie — Grandissent du robot alors là j'imagine que la stabilité ça serait pas la même tu me.

Bruno — Disais il fait 10 cm d'eau mais où est-ce que tu ranges les jambes pour.

Sophie — Les déplier ça.

Bruno — Va être quelque chose de ouf.

Sophie — Et c'est pas un robot non plus qui va monter qui va tourner, qui va monter à la verticale il reste toujours.

Bruno — À plat à horizontal je sais que je t'avais posé la question en préparation mais cette crémaillère à laquelle vous vous écrochez est-ce qu'il y a un lien avec la pendaison de crémaillère qu'on fait et j'ai complètement.

Sophie — Oublié du coup je ne sais pas je n'ai pas cherché.

Bruno — Bon dommage ok donc du coup ça répond à ça j'avais une autre question alors du coup je rechange le sujet c'était sur ces notions de convoyeur que tu as évoqué tout à l'heure, est-ce que c'est encore des convoyeurs à l'ancienne avec un tapis qui tourne est-ce que maintenant on est de manière automatique c'est une espèce de petite boule où du coup tu peux bouger en tout en omnidirectionnel sur le tapis non c'est.

Sophie — Des rouleaux c'est essentiellement des rouleaux en fait t'as des cylindres qui tournent et qui vont entraîner la charge de.

Bruno — Proche en proche.

Sophie — C'est essentiellement ça. Et on a encore beaucoup des... Alors, des tapis, nous, on ne fabrique pas, mais c'est essentiellement à base de rouleaux ce qu'on produit. Mais voilà, il y a aussi... Ça existe encore, des tapis. C'est plus complexe de diriger qu'en termes multidirectionnels. Je ne dis pas qu'il y en aura peut-être... Peut-être dans l'avenir, j'en sais rien. On ne sait pas.

Bruno — Pour revenir du coup sur les solutions de robotique sur son « goods to person ». J'en profite pour du coup reprendre un petit peu tout ce qu'il se dit dans le chat donc par rapport à ce qu'on dit tout à l'heure sur cette, comment j'ai retrouvé un trait particulier des devs pour le monde de la robotique il y avait le 15 qui nous dit c'est le côté enfant qui ressort l'émerveillement de voir un jouet s'animer c'est un petit peu ça, c'est des gros jouets c'est des gros jouets qui valent un peu cher aussi, et du coup il y a une question aussi de Julien Est-ce que l'arrivée du machine learning est un game changer dans les systèmes d'optimisation de trajet ? Ou les approches algorithmiques old school type réseau de fourmis restent indétrônables ?

Sophie — Le machine learning, c'est un outil parmi d'autres pour faire de l'algorithmique, pour faire de l'optimisation. Nous, on en a, mais c'est pas... On ne se vend pas, on ne se représente pas comme une entreprise à la pointe parce qu'elle fait du machine learning. Ça fait partie des compétences qu'on a en interne, qu'on utilise. Mais on ne va pas se dire qu'on fait du machine learning pour faire du machine learning. Aujourd'hui, le machine learning, on l'utilise plutôt pour la vision, pour reconnaître, pour notre bras robotisé, pour Skype, pour reconnaître, pour détecter quel article il doit prendre et surtout le poser au bon endroit dans le bac de façon à faire un peu un Tetris le plus intelligent possible. Parce que bon, s'ils posent... T'imagines, t'as un bac qui fait, je sais pas moi, 60 par 40 et puis tu poses tout au milieu empilé. Bon, ça va tomber. Si au-dessus, c'est une bouteille d'huile, c'est un petit peu dommage. Tu risques de tout casser. Donc voilà, placé correctement, dans le bon sens, etc. Là, on a plus besoin d'apprentissage et de machine learning. Mais, les algos old school ont encore, je pense, de beaux jours devant eux parce qu'ils sont efficaces, en fait. parce qu'il y a encore des choses super efficaces là-dedans.

Bruno — Donc, le déplacement du robot dans l'espace, ça, ça reste de l'algorithmie, entre guillemets, à l'ancienne.

Sophie — Oui, si on veut. À l'ancienne, dans le sens, ce n'est pas ce qu'on appelle du machine learning. Par contre, quand même à la pointe, parce qu'aujourd'hui, on a des algos que nous, on a industrialisés qui sont, d'un point de vue universitaire, encore des papiers de recherche pas aboutis et pas industrialisables. Donc, on fait quand même, on va plus loin que la recherche universitaire sur certains domaines algorithmiques donc certes c'est une façon de coder un peu plus à l'ancienne parce que c'est pas ce qu'on appelle du machine learning mais, il faut pas croire que c'est juste reproduire des algos qui sont documentés etc on a des tas de choses, elles sont pas documentées si t'es pas dans la boîte t'en as aucune idée.

Bruno — Je pense que du coup la question aussi sous-jacente de Julien en tout cas celle que moi j'ai c'est À quel point est-ce que ces algos, c'est juste une succession de if versus un apprentissage de donner une capacité de décision au robot ?

Sophie — Non, au final, je pense que c'est compliqué. C'est compliqué parce que même donner une capacité de décision, au final, au fond du truc, c'est quand même une succession de ifs. Donc, c'est un petit peu complexe. Il y a un peu d'apprentissage, mais c'est quand même surtout des ifs et des boucles qui se succèdent, mais qui se succèdent de façon... Ou très intelligemment pensé et optimisé.

Bruno — Et quel est la... Parce qu'il y a forcément un choix qui a été fait de répartition, entre guillemets, de l'intelligence entre ce que le robot est capable de... Enfin, le robot qui se déplace est capable de faire tout seul versus, vous avez un orchestrateur, si j'ai bien compris, qui mappe un petit peu tout ça. Donc, il y a un choix qui a été fait de se dire il y a une partie qui va dans l'orchestrateur, une partie qui va dans le robot. Ma question du coup c'est comment est-ce que ça a été réparti et comment est-ce que cette répartition a été décidée, tu vois, comment est-ce que tu drives en fait, comment tu choisis ce que tu mets d'un côté ou de l'autre.

Sophie — Alors j'étais pas là au tout début de l'entreprise donc je saurais pas te dire exactement au début de l'entreprise comment ce choix a été fait aujourd'hui donc on a un orchestrateur Astar, qui est notre logiciel qui est capable de piloter jusqu'à 200-250 robots et, Et ces robots sont dans un endroit clos. C'est-à-dire que tu ne peux pas avoir d'humain, tu n'as pas d'interaction extérieure, tu n'as rien d'autre. Donc je pense que ça, c'était quelque chose d'important. Au début, ça a déjà été un premier choix. Est-ce que le robot se déplace parmi des humains ou est-ce qu'il ne se déplace pas parmi les humains ? Ce n'est pas les mêmes problématiques.

Bruno — On est un peu plus mou qu'un robot ?

Sophie — On est un peu plus mou qu'un robot et puis les normes de sécurité ne sont pas du tout les mêmes quand tu es capable de dire « Non, mais mon robot ne pourra pas sortir parce que si jamais il sort, la sécurité se met en marche et t'as tout qui s'arrête. Ou alors le bon robot doit être capable d'interagir avec des événements complètement imprévus. Donc le choix a été fait. Nos robots sont dans un espace clos et non franchissables par un humain. Et après, l'orchestration globale, alors il y a certainement eu des tests au début, mais l'orchestration globale, c'est-à-dire le choix des trajectoires globales des robots est faite par notre orchestrateur. Et après, le robot, il ne faut pas croire que du coup, c'est juste un robot bête qui suit la trajectoire. En fait, on a vraiment de l'algorithmique aussi assez poussée au niveau du robot, avec des modèles type MPC. C'est-à-dire, c'est du modèle prédictif observer. Tu utilises ta réalité, ta géométrie, justement pour modifier le modèle purement théorique qui a été calculé. Tu l'utilises aussi en input et du coup tu t'adaptes parce que chaque robot en fait il a sa propre géométrie ils sont jamais, si on en sort mille, ils ne vont pas tous exactement identiques chaque roue va avoir peut-être une petite différence de quelques millimètres, de diamètre ce genre de choses tu as toutes ces marges d'erreur qui font que même si tu donnes à trois robots différents exactement la même trajectoire si tu n'utilises pas en entrée, en correction on va dire de ton modèle, si tu n'utilises pas les mesures réelles, ça ne marche pas. Parce que tes robots, ils ne vont pas suivre la trajectoire que tu leur as donnée.

Bruno — Est-ce que du coup, il y a aussi une influence qui est amenée par le fait qu'il est chargé ou pas et qui peut être chargé par 10 kilos ou par, je ne sais pas, quel est le poids maximum qu'un robot peut transporter ? Mais tu vois, est-ce que ça s'est pris en compte aussi dans cette optimisation de son propre parcours ?

Sophie — Oui, au travers de ces mesures, en fait. Donc, il peut porter jusqu'à 30 kilos. Donc, on a des bacs qui contiennent, pardon. Le contenu des bacs, c'est à peu près 30 kilos. Donc, il faut rajouter son propre poids et puis le bac. Mais justement, si tu fais un modèle qui tient compte de la réalité, donc c'est la réalité, c'est à quelle vitesse mon mérou, ça va être qu'est-ce que j'ai pu observer avec mon laser, ce genre de choses. En fait, tu t'adapteras quel que soit le poids qui est dessus. Tu t'adapteras en permanence.

Bruno — Donc en fait ton orchestrateur va suggérer un trajet.

Sophie — À un.

Bruno — Robot qui va le suivre à peu de choses près sauf s'il y a une condition qui fait que.

Sophie — Il va suivre ce trajet et si jamais il y a un obstacle ou quoi que ce soit il va s'arrêter parce qu'il va pas être capable de en fait ce qu'on veut pas c'est que des robots se rentrent dedans parce que ça coûte un petit peu cher et puis que ça fait tout arrêter, donc ce côté Je sais où sont mes robots à tout moment, c'est l'orchestrateur qui a cette vision-là, c'est Asta. Par contre, le robot, lui, il faut que taille de tel point à tel point en suivant à peu près telle trajectoire, et lui, il se recale en permanence sur cette trajectoire. Mais là-dessus, il y a de l'optimisation intéressante. Là, c'est vraiment de la robotique embarquée. On est sur du C++, mais très très proche du C en réalité. Au début, les premiers algos qui ont été faits, tu prends ce que tu peux trouver dans la littérature, tu l'implémentes, tu as une tente de réponse d'à peu près une seconde. Une seconde, en robotique, il se passe beaucoup de choses. Nos robots, ils vont à au maximum 4 mètres par seconde. Ça fait du 20 km heure à peu près. Tu cours à côté, il faut être un bon coureur. Donc à 4 mètres par seconde, une seconde, tu as été loin. Donc il y a eu des tas d'optimisations là-dessus. Aujourd'hui, on est à autour de 4 millisecondes, notre boucle. Donc là, on a vraiment de l'optimisation on a des devs qui sont ultra forts en optimisation de code de code embarqué justement pour garder la même précision, mais en allant vachement plus vite.

Bruno — Et oui c'est intéressant parce que moi quand tu me dis on a un temps de réponse d'une seconde je me dis bah en fait c'est le temps que t'envoies la route ça prend une seconde c'est pas grave après le robot il démarre et il suit son trajet mais en fait c'est que t'as besoin d'optimiser, c'est à dire que tu peux changer le trajet d'un robot pendant qu'il est en route ?

Sophie — Non on l'envoie pas non non mais c'est en fait Et... La boucle, si tu veux, de calcul interne au robot pour se remettre sur sa trajectoire, au début, quand on l'a codé, elle mettait une seconde. La complexité était telle que ça prenait une seconde de calcul. Une seconde de calcul, pendant ce temps-là, ton robot, il avance. Et s'il a été à 4 mètres par seconde, il peut avoir beaucoup de déviés puisqu'il aura avancé de 4 mètres. Et c'est là qu'on a optimisé. Parce que non, on ne change pas la trajectoire du robot. On attend qu'il soit arrêté pour lui renvoyer une nouvelle trajectoire.

Bruno — Alors, du coup, j'essaye de... Parce que d'un côté, tu me dis que le robot, il va suivre le trajet qu'on lui a donné, mais en même temps, je sens qu'il a une capacité d'adaptation en fonction de ce qu'il rencontre. Du coup, à quel point il...

Sophie — Il va... Non. Il va s'adapter... Il va... Comment dire ? Il va adapter ses mesures... Enfin, il va utiliser ses retours de mesures pour justement rester sur la trajectoire qu'on lui a donnée. Et s'il s'en éloigne trop.

Bruno — Il s'arrête.

Sophie — Parce que.

Bruno — Du coup il peut y avoir une roue qui va plus vite que la roue de droite qui va plus vite que la roue.

Sophie — De gauche.

Bruno — Et du coup il faut qu'il se réajuste pour se remettre en permanence sur.

Sophie — Le trajet ou alors tu vas avoir un petit problème de planéité tu as une petite bosse à un endroit où il y a une vis qui est tombée du coup ça va le dévier un petit peu et donc il va se remettre en permanence ou alors le bac qu'il a sur le dos, n'est pas équilibré en termes de poids parce qu'on a des bacs qui sont, je sais plus, 40 par 60 je crois, en centimètres, 400 par 600 et si tu veux stocker des vis par exemple, t'as pas besoin d'un bac comme ça, c'est trop grand, donc on peut le diviser en petits morceaux. Mais du coup si c'est divisé en deux et que t'as que du poids dans une des deux divisions et pas dans l'autre, ton robot forcément ça... Tu vas dévier sa trajectoire.

Bruno — D'accord.

Sophie — Et donc, il faut que ça remette en permanence, justement, ça mette plus de vitesse, plus de couple dans l'autre moteur pour retourner sur sa trajectoire.

Bruno — Alors, c'est compliqué parce qu'en fait, à chaque fois que tu m'expliques un truc, j'ai trois questions qui arrivent, mais du coup, il faut que je pense à revenir à la question d'avant. Tu as évoqué, donc, il va se réajuster, notamment s'il voit une petite bosse à un endroit, un truc et compagnie. Du coup, moi, je me dis, OK, donc, tu as un orchestrateur, tu as un robot qui s'ajuste pas parce qu'il y a une petite bosse sur le trajet. Est-ce que ton orchestrateur est capable, à force de voir qu'au même endroit, à chaque fois, les robots sont obligés de se réajuster parce qu'il y a un défaut dans le terrain, de se dire, OK, là, il y a un défaut, donc à l'avenir, on va l'éviter sur les trajets.

Sophie — Ah non, mais l'orchestrateur, il n'est pas au courant de ça.

Bruno — D'accord.

Sophie — L'orchestrateur, il sait juste, est-ce que je suis au bon endroit ? Enfin, le robot lui remonte juste l'information de où il est, et s'il est au bon endroit, moyennant une petite marge, c'est OK. L'orchestrateur ne va rien faire. mais il sait pas tous ces retours de calcul sont purement internes au robot ces retours de mesure et ces recalcules et cette optimisation du modèle en permanence c'est purement internes au robot et le robot il ne remonte que quelques informations à l'orchestrateur t'imagines tous ces robots là t'imagines t'as 200 robots qui discutent en wifi à.

Bruno — 20 km heure ?

Sophie — Non oui à 20 km heure oui alors en général ils sont plutôt à 3 mètres par seconde que 4 mètres par seconde parce que 4 mètres par seconde il faut qu'ils soient en ligne droite lancés etc ils tournent pas aussi vite que ça ? Si tu veux remonter toutes ces informations en permanence, t'imagines la quantité de data que tu dois remonter via le wifi. En fait, ça passe pas. Ça a été assez intéressant. Il y a aussi des tas de choses. On fait de l'optimisation là-dessus. Justement, quand tu commences à dire, je vais remonter ça, ça, ça, ça, et puis que tu vois que ta bande passante est complètement saturée, tu commences à dire, bon, il va falloir que j'optimise bit par bit ce que je remonte comme information. Du coup, au début, on utilisait des protocoles mainstream, et en fait, on a recodé un protocole c'est du TCP c'est des sockets TCP mais on a recodé notre protocole pour optimiser justement le contenu des messages qui sont envoyés pour ne pas perdre de bande passante pour qu'on puisse avoir 200 robots qui communiquent en permanence avec notre orchestrateur.

Bruno — Et alors du coup ce plafond que vous avez jusqu'à 200 robots pour un orchestrateur est-ce que du coup c'est dû notamment aussi à une limitation de communication, ou c'est une question de capacité de calcul de trajet ?

Sophie — Au début, c'était un problème de communication. On a vachement travaillé justement sur ça parce que le Wi-Fi n'était pas capable. On a changé un petit peu aussi notre façon d'organiser les access points Wi-Fi sur un site. Aujourd'hui, ce n'est plus la communication. Le problème, c'est effectivement plutôt la capacité de calcul. Parce que si à un moment donné, tu démarres ton site, tu lances ton site, etc. Tous tes robots, ils étaient à l'arrêt. Et là, tous tes robots, ils veulent une nouvelle mission, ils veulent savoir ce qu'ils veulent faire. Donc t'es en train de calculer 200 missions en permanence en parallèle, donc c'est du modèle ultra multi-thread qu'on a, et en fait quand t'as trop de robots tes threads ils sont en permanence en train juste de vérifier s'ils peuvent prendre des mutex et t'as plus de place t'as plus de temps de calcul réel parce que t'as trop de temps comme ça donc on observe, on pourrait sûrement en mettre plus mais on observe qu'en fait. Sur le cas nominal ça marche quand t'es en régime établi, tes robots ils sont pas tous en train de demander des missions en même temps donc ça marche, mais au moins de petits problèmes dès que tu commences à avoir une surcharge de calcul ça prend des plombes et c'est pas acceptable. En fait ce qui est assez intéressant c'est qu'on parle des robots mais au final, c'est des personnes qui sont utilisatrices du système, c'est des personnes qui sont devant les stations à attendre que le robot amène le bac. Et donc si on a des problèmes si le robot il attend trop, si il y a des collisions, si on a du mal à calculer leur mission, au final le gars, il va être là, puis il va se tourner les pouces. Et puis t'attends, si t'as aucun robot qui arrive, normalement, pareil, en régime nominal, t'as 4-5 robots, ça s'appelle une station, t'as une espèce de rampe comme ça, qui monte vers l'opérateur. T'as toujours 4-5 robots qui sont là, et puis c'est fluide, en fait, quand le robot il part, t'en a un autre qui arrive juste après, parce qu'il attendait juste... Mais s'il s'est produit quelque chose, et puis tu vois pas de robot, puis que tu vois pas de robot, puis que tu vois toujours pas de robot, tu te demandes ce qui se passe. Donc, en fait, dès que tu perds quelques secondes, au final, c'est l'opérateur de préparation de commande qui attend.

Bruno — Et puis, il y a des effets cascades, du coup.

Sophie — Exactement. Exactement. Tu as des effets cascades dès que tu commences à avoir un problème quelque part. En général, il y a tout un travail d'optimisation là-dessus pour cascader le moins possible et puis essayer de limiter dans une zone particulière dès qu'on a un problème, justement. Tout ça, c'est le travail de l'orchestrateur aussi.

Bruno — Je vois. Je reviens un petit peu plus haut parce que cet aspect réseau, c'était justement, là-dessus. Il disait qu'au-delà du compute, il faut être ensuite capable de communiquer entre tous ces acteurs. Il parlait notamment de la gestion des ondes. Tu parlais tout à l'heure, vous avez modifié la façon dont les points Wi-Fi sont installés. Est-ce que c'est parce qu'il y avait une espèce de pollution, une pollution, électromagnétique ? Il y avait tellement d'éléments qui communiquent au même endroit qu'il y avait une espèce de...

Sophie — Non, pas ma connaissance. C'était plutôt parce que, il faut imaginer dans un entrepôt comme ça, donc si tu as un entrepôt qui est à 12 mètres de haut, et tu as l'espace entre deux étagères, l'espace où il va passer les robots fait 60 cm, l'espace d'un robot. C'est ultra dense, c'est vraiment ultra dense, c'est que du métal, et puis après du stock, et du coup, le wifi, le métal, tout ça, ça ne marche pas bien. Et donc il faut que, où que soit le robot, il soit systématiquement connecté Wifi, il ne faut pas qu'il perde la connexion. S'il perd la connexion, on considère qu'il est perdu, et un robot perdu, justement, ça cascade partout. Et donc... Il a fallu optimiser la position des access points pour que les robots, à aucun moment, ils perdent la connexion, qu'ils puissent sauter d'un access point à l'autre en ayant suffisamment de connexions et de pouvoir continuer à discuter en permanence.

Bruno — Et du coup, le choix du Wi-Fi, est-ce qu'il y a eu d'autres tests ? J'imagine que le Bluetooth, bon, c'est pas ouf.

Sophie — Ouais, c'est pas très difficile.

Bruno — Est-ce qu'il y a eu des tests de plusieurs types de connexions ?

Sophie — Je sais pas. Là, pour le coup, je sais pas.

Bruno — C'est prêt, c'est avant ton arrivée ?

Sophie — Oui, exactement. et vu que c'est pas le domaine dans lequel je travaille je suis au courant d'un certain nombre de choses mais c'est vrai que je me suis pas intéressé à tout il y a tellement de choses intéressantes dans l'entreprise en fait que tu peux pas savoir les raisons de tous les choix techniques.

Bruno — Je vois déjà moi j'ai qu'une heure avec toi donc je dois choisir les sujets que j'évoque donc j'imagine que t'es effectivement ces sujets là aussi, Il y a, donc l'orchestrateur, c'est l'orchestrateur qui va choisir le trajet. Est-ce que dans un souci de facilité, vous prédéterminez un ensemble de routes, et du coup il y a des croisements qui sont faits, et du coup c'est un GPS traditionnel, c'est-à-dire que tu as un ensemble de points de départ et un ensemble de points d'arrivée, ou est-ce que l'orchestrateur peut faire passer un robot littéralement par n'importe où, et du coup parfois t'as des trajets un peu, avec des courbes, j'ai plus le nom au terme, peut-être pas gaussiennes si gaussiennes, t'as des vrais virages et compagnie ou est-ce que tu vois c'est...

Sophie — Alors en fait on a on a représenté nos routes par un graphe pour être sûr que les robots passent bien au centre par exemple entre deux, étagères, tu peux pas faire se croiser des robots déjà c'est important, tu peux pas faire croiser des robots Donc entre les étagères, le chemin est à sens unique. Donc en fait, on a tout un réseau de chemins. En fait, c'est vraiment littéralement un graphe de chemin, un graphe orienté, avec certains chemins qui sont à sens unique et d'autres qui sont à double sens à d'autres endroits, avec des points où les robots ont le droit de s'arrêter, et puis sur le chemin, ils n'ont pas le droit de s'arrêter. Mais les points où ils peuvent s'arrêter, en fait, ils ont leur place de garage, on va dire. Donc tu as autant de place de garage que de robots, parce que quand t'arrêtes un système, il faut que le robot soit dans ses places de garage. Si t'as 100 robots sur ton système, tu vas avoir 100 places de parking. Et puis après, chaque point d'arrêt ou de départ, c'est justement les alvéoles, c'est-à-dire là où sont situés chacun des bacs dans le système. Là, le robot a le droit de s'arrêter parce que forcément, il faut qu'il s'arrête pour récupérer son bac. Et après, l'orchestrateur, moyennant, en suivant ce graphe-là, en utilisant ce graphe-là, il peut faire n'importe quel chemin. Donc oui, Des fois, on a des trucs assez bizarres avec des robots parce qu'on a un visualisateur. Moi, je peux me connecter partout dans le monde et voir tous les robots sur leur site et voir les chemins en temps réel, les chemins qui sont choisis justement par Astar. Et au début, on avait des trucs assez drôles avec des robots qui faisaient des tours, en fait, parce que pour une raison ou pour une autre, à un moment donné, il y avait d'autres robots sur la route. Donc, l'orchestrateur estimait que c'était plus rapide de faire un tour et puis de revenir au point de départ plutôt que d'aller tout droit et d'attendre. Bon, ça, on a essayé d'éviter parce que c'est rarement optimal de faire un petit tour, ça, en général, que tu as un problème dans ton algo. Mais oui, on a des fois des chemins assez bizarres parce qu'en fait, l'orchestrateur, il tient compte de la position. Il n'est pas que spatial, en fait. Il tient compte de la position dans le futur de chacun des robots. Donc, il doit optimiser le chemin en temps et pas seulement en distance. Donc, il optimise en distance et ensuite, il adapte en fonction de... Ah oui, mais là, à ce moment-là, j'aurais tel robot. Donc, peut-être que si je fais un petit détour ou peut-être que si j'attends ou que je vais moins vite ou plus vite avant, je vais pouvoir optimiser en temps mon trajet.

Bruno — Donc il va optimiser les croisements, quitte à en faire ralentir un petit peu pour qu'il y en a un autre qui passe de manière plus safe au croisement et que l'autre arrive juste après alors c'est celui d'après.

Sophie — C'est toujours c'est quand, c'est à partir du moment où on a choisi un chemin pour un robot on l'inscrit, alors en cache mais on l'inscrit et il ne bougera plus, on l'envoie au robot cette mission là et donc ce robot là, vu qu'on ne change pas le trajet d'un robot en cours elle est envoyée et donc c'est les autres qui vont s'adapter à celui là.

Bruno — Attends j'avais une question elle vient de partir euh, j'en ai une autre derrière c'est pas grave tu nous as dit que le chemin du coup entre les étagères est à sens unique tu nous as dit aussi qu'il y a une particularité c'est que vos robots ils sont capables de monter aux étagères, est-ce que ton orchestrateur il a pour objectif que si le robot, 3 est derrière le robot 2 il restera quoi qu'il arrive derrière ou si jamais le robot 2 commence à monter le robot 3 peut passer en dessous complètement.

Sophie — Le 3 peut passer en dessous donc.

Bruno — En fait t'as une géométrie spatiale t'es pas juste sur des trajets en 2D mon graphe il est pas que en 2D.

Sophie — Il est en 3D il sait jusqu'où il va il sait s'il est en train de monter, de descendre ou s'il a l'arrêt en train de sortir en train de sortir sa fourche ou pas tu peux même avoir, le robot 3 qui monte, qui monte jusqu'à 10 mètres et puis le robot 2 qui monte, jusqu'à 2 mètres, pendant que le robot 3 est à 10 mètres, et puis ensuite le robot 2 qui repart et le robot 3 qui redescend.

Bruno — Ouais j'avais lu un jour un article de quelqu'un qui expliquait que la probabilité qu'on ait des voitures volantes dans le futur est quasi nulle parce qu'en fait déjà quand on se déplace dans un espace à deux dimensions quand on continue une voiture dans un espace à deux dimensions c'est très compliqué alors si on devait imposer à l'humain de se déplacer aussi à la verticale ça deviendrait accidentogène il y aurait des morts toutes les 20 secondes dans toutes les villes, ma question du coup c'est est-ce qu'en informatique dans votre cas précis vous avez quand même des trajets qui sont quand même bien définis et compagnie est ce que cette troisième dimension est ce que ça ça t'augmente la complexité est ce que ça te cube la complexité ou est ce que ça te la multiplie par trois ou est ce qu'au final c'est pas une complexité puisque c'est.

Sophie — Une bonne question à, je pense qu'avec notre modèle de données ça ne l'augmente pas en tout cas on ne change pas de complexité, justement alors tout ça ça fait partie de ce truc dont je te disais aujourd'hui dans les papiers officiels dans les papiers universitaires il n'y a rien qui marche en 3D alors que nous on a quelque chose d'industriel donc je ne peux pas trop te détailler, justement ce qu'on fait mais je pense que non ça n'augmente pas la complexité on a réussi à trouver une façon de gérer le truc qui n'augmente pas la complexité.

Bruno — C'est peut-être lié au fait que comme votre robot monte en s'accrochant aux étagères, tu as un nombre de chemins défini, alors que tu n'as pas un robot qui va monter d'un coup en diagonale entre les étagères. C'est des parcs qui sont à fait.

Sophie — En fait, on arrive à remettre à plat quelque part. D'une certaine façon, on remet à plat cette 3D. Ce n'est pas tout à fait ça, mais d'une façon, on se ramène à de la 2D d'une manière ou d'une autre.

Bruno — Il y a alors je suis désolé, j'ai des questions qui commencent par des petites histoires, j'ai vu il y a longtemps c'était une des premières démos des voitures autonomes de Google donc c'était il y a presque 10 ans voire même 15 ans, j'avais vu une vidéo de Sergei Brin qui est monté dans une voiture autonome avec sa maman à l'arrière et en fait ce qui était assez choquant, ça a changé depuis à l'époque c'était vraiment le début des voitures autonomes il y avait un parcours qui était défini, et en fait sa maman était terrorisée notamment parce qu'il y avait un point particulier, c'est comme la voiture a été dirigée par un robot qui connaissait exactement les points de friction de chaque roue, la vitesse qui maîtrisait vraiment au newton-mètre précis, l'accélération et compagnie, elle prenait la trajectoire optimale de machin et du coup la voiture elle était à 80 kmh dans un virage où en tant qu'être humain, tirait jamais à 80 kmh donc tu vois c'était assez flippant ma question c'est du coup est-ce que, tu nous disais tout à l'heure que quand il y a un trajet qui est défini, le trajet ne bouge plus, c'est les autres qui vont s'adapter, mais tu nous as dit aussi en fonction des roues des machins des robots qui vont parfois ralentir accélérer qui doivent du coup optimiser le trajet, C'est quoi la marge de manœuvre que vous venez de faire ? Vous n'avez pas envie que les robots se cassent. Quand tu dis que tu vas faire ralentir un robot, parce qu'à priori, il va y avoir un robot à cet endroit-là au moment où il arrive sur le croisement, si jamais il y a un robot qui ralentit un peu trop parce qu'il y a un truc sur la route, il y a une vis qui se détache, ou il y a une perte d'adhérence, ou je ne sais quoi, à quel point l'urgence peut être gérée ? Attention, il va y avoir collision, on arrête tout.

Sophie — Déjà, ils sont... ils savent à l'avance quand on envoie leur mission au robot ils savent aussi quels sont les obstacles normaux qu'ils vont voir sur leur route autrement dit ils savent s'ils doivent croiser ou pas, ils savent d'une certaine manière ils savent ils savent pas que c'est un robot mais ils savent qu'à un endroit ils vont avoir un obstacle normal sur leur route donc ils vont réagir.

Bruno — Je me permets de te couper parce que c'est ouf ça veut dire que quand t'envoies le trajet à un robot tu lui dis tu vas passer par là et à tel endroit, tel endroit, tel endroit tu vas voir un truc à ta gauche qui passe ou à ta droite, mais c'est normal.

Sophie — On envoie suffisamment d'informations pour qu'il ne soit pas étonné.

Bruno — Et du coup, s'il voit un truc qui ne correspond pas à ce qu'on lui donnait, il s'arrête ?

Sophie — Alors, il commence par dire c'est normal ou c'est pas normal ? Il demande à l'orchestrateur tout va bien ?

Bruno — D'où l'importance des temps de réponse.

Sophie — On n'envoie pas vraiment tous les robots. On envoie des informations parce que, en fait c'est trop simplifié c'est trop simplifié et en même temps je peux pas te donner tous les trucs compliqués parce que justement c'est notre valeur ajoutée, parce que t'imagines bien qu'on peut pas lui envoyer des robots qu'on connait pas encore alors il y a d'autres robots qui vont venir à un moment etc. Il connait des géométries qui font que il va pas s'étonner sur certains robots il va s'étonner sur d'autres mais il va commencer par dire justement attention il y a quelque chose pas trop loin qui se rapproche un peu vite qui se rapprochent, c'est normal, c'est pas normal. Et si au bout d'un moment, Astar dit « Ah non, non, c'est pas normal, tu devrais rien avoir à cet endroit-là », hop, on arrête le robot. Et le fait d'arrêter un robot, ça propage à tous ceux qui devaient passer, justement, là, ça propage l'erreur en disant « Non, non, toi, tu devais venir dans 10 secondes, tu devais passer par là, mais en fait, tu peux pas passer parce qu'il y a un robot qui est arrêté, donc tu t'arrêtes là où tu es. Mais du coup, comme tu t'arrêtes, tu propages, etc. » Donc, on essaie de minimiser, justement, de réduire les marges au maximum, que ça ne propage pas trop. Parce que si tu commences à propager à 200 robots, tu as arrêté ton site. Et en même temps, avoir suffisamment de marge. Donc la marge, elle va dépendre de la vitesse, elle va dépendre du site, elle va dépendre de la fiabilité. Elle dépend de plein de choses. Il y a des sites où on avait des problèmes à certains endroits, toujours le même. En fait, on s'est rendu compte que tu as des puits de lumière à certains endroits, dans des entrepôts. Et ça, ça avait des impacts sur nos lasers. Et donc, ça avait des problèmes. Les robots avaient du mal à se localiser, justement, à ces endroits-là. Il y a plein de petites anecdotes de trucs auxquels on n'avait pas pensé. Tu fais ton truc, tu te dis, OK, je vais penser dans le cas un peu théorique, il va se passer ça, ça, ça. Déjà, quand tu passes sur du hardware, le théorique, ça ne marche plus bien. Et en plus, ça va marcher chez un client, ça va marcher dans un deuxième entrepôt chez un autre client, puis tu vas le mettre chez un autre client. Tu as la même chose, puis tu fais, ça ne marche plus. On n'a pas la même fiabilité, on n'a pas la même robustesse. qu'est-ce qui se passe, pourquoi. Donc là, il faut analyser pourquoi dans ce cas-là, dans cette configuration-là, on a tel ou tel problème avec des trucs assez drôles du style, en fait, il y a une fenêtre et à telle heure, le soleil il est au-dessus et du coup, ça a un impact sur le robot.

Bruno — Moi, il y a une phrase que j'aime beaucoup qui est que la théorie est toujours vraie, sauf dans la pratique.

Sophie — C'est assez vrai.

Bruno — C'est ça. Alors, j'avais évoqué en début d'épisode, effectivement, que je voulais parler de comment est-ce que tu testes ça, mais j'ai plein d'autres questions avant. Il y en avait une j'en ai encore oublié une il y en avait une autre du coup sur, ce système de gestion de couches parce que du coup t'as Astar qui va définir l'ensemble des trajets t'as ton robot qui va se déplacer et après t'as le picker, ça j'ai plus le nom exact le skypeeker qui lui du coup va se déclencher après pour récupérer l'objet, Pourquoi il y a cette distinction entre celui qui se déplace, dont j'ai oublié le nom aussi, et le skypod, et le skypeaker ? C'est histoire de gérer la responsabilité de chacun et d'éviter des interférences ou je ne sais quoi ?

Sophie — En fait, tu veux, le skypod, c'est le robot, pas tout à fait cubique, mais quasiment, qui va se déplacer et qui amène les bacs. Et en fait, le skypeaker, il vient en lieu et place d'un humain. Alors, ce n'est pas tout à fait la même géométrie, ce n'est pas fait de la même façon, parce que justement t'as un robot donc t'as des problèmes de sécurité, il faut que ce soit dans une zone fermée etc mais ce skypeaker lui il est fixe c'est juste un robot fixe avec un bras, et l'autre robot vient et le skypeaker d'un point de vue Astar parce que c'est Astar qui le pilote aussi qui lui donne ses missions de la même façon qu'il donne des missions au robot alors lui il lui donne des missions de dire tu prends tant d'articles dans telle partie du bac et tu les mets dans tel bac et là c'est le skypeaker qui va calculer entièrement sa trajectoire, pareil, qui va vérifier où est placé l'article, vérifier comment est la géométrie de là où il doit le positionner, prendre le truc, sortir du bac, etc. Mais t'as besoin d'un orchestrateur, parce que tu veux pas, par exemple, que le robot d'en bas, il commence à bouger, alors que l'autre, il est encore dedans. Parce que là, tu casses pas un robot, mais t'en casses deux, et puis le bras robotisé, c'est plus cher que l'autre robot, donc, T'as toute une gestion comme ça de sécurité du matériel qu'il faut via un orchestrateur.

Bruno — Mais du coup, le Skypicker, il est sur le Skypod ?

Sophie — Ah non, le Skypicker, il est fixe à un endroit donné de l'entrepôt. Et c'est le Skypod qui amène les bacs jusqu'au Skypicker, comme il les amènerait à un humain.

Bruno — Et du coup, j'ai mal compris le truc. Du coup, le Skypicker, il est au niveau des étagères pour mettre les éléments dans le Skypod ? Il est au niveau de ce.

Sophie — Qu'on appelle les stations, c'est-à-dire l'endroit de l'opérateur exactement, il est à côté des opérateurs enfin dans sa petite cage mais il est à côté des opérateurs pour commencer les commandes pour tout ce qu'on appelle skypeakable c'est-à-dire des articles que le skypeaker sait récupérer, sans trop d'erreur.

Bruno — On me dit dans le chat qu'effectivement les puits de lumière ça a été évoqué sur un autre épisode qui est entre guillemets un peu similaire, c'est que j'ai fait un épisode sur la détection visuelle sur un système de caméras qui, sur une chaîne de fabrication, voient passer toutes les pièces et analysent les pièces qui ont été défectueuses. Et ils ont eu le même problème d'un puits de lumière qui, d'un coup, entre midi et 13h, fait que le reflet n'est plus le même sur les pièces. Et du coup, il y a un taux de rejet qui est plus important. C'est marrant de se dire que, dans un monde industriel, la lumière, c'est pas...

Sophie — Non, on n'aime pas trop. Et en fait, les skypods, ils n'ont pas besoin de lumière. Donc, tu peux éteindre la lumière complètement. D'ailleurs, il fait très, très sombre. Quand tu es au milieu du rack, c'est extrêmement sombre.

Bruno — J'imagine que des étagères de 12 mètres de haut qui ont 60 cm d'écart déjà ça te bloque pas mal de lumière C'est ça, exactement, Sur, du coup, cette notion de test, où effectivement la théorie est toujours vraie, sauf dans la pratique, tu as des contextes qui sont très différents. Comment tu fais pour tester de manière suffisamment fiable ton système, pour que quand tu le mets en prod, parce que j'imagine que ça coûte quand même très cher à une entreprise de mettre ça en place, que tu ne peux pas te permettre de lui dire, en fait, finalement, il faudra acheter 20 robots parce qu'il y a un bug qui fait qu'on en a pété 20 la première semaine. Comment tu fais pour bien tester ton truc et pour que la mise en prod se passe sans accroître ?

Sophie — Il y a plein de choses on a tout un travail qui a été entamé un peu après le début de l'entreprise parce qu'au début tu dev et puis après, justement avec des devops on a énormément de devops en ce moment toute notre équipe infra elle est en train de monter, justement pour automatiser au maximum en termes de CI aussi pour tester au fur et à mesure dès qu'on fait des merges, enfin dès que tu veux faire un merge de tester que t'as rien cassé donc t'as tout un tas de tests automatiques mais alors ça c'est vraiment à la limite les tests automatiques c'est le truc où en ce moment on recrute énormément parce que. On n'est pas suffisamment industriel là-dessus c'était pas les priorités à l'origine de l'entreprise c'est normal et maintenant il faut qu'on s'améliore énormément là-dessus donc il y a d'énormes chantiers sur cette partie automatisation de tests pour faire tourner des tas de scénarios différents justement pour vérifier que ça continue à marcher. Parce que t'as plein de choses. Tu veux que ton robot continue à fonctionner. Tu veux que ton orchestrateur qui gère la partie trafic continue à fonctionner. Tu veux aussi que t'intégrer dans le contexte logistique du client. C'est-à-dire que le client, lui, il nous envoie des listes d'articles. Il dit, voilà, toutes mes références et voilà mes commandes. Mais en fait, d'un client à l'autre, faire une commande, préparer une commande, c'est pas la même chose. T'as des clients qui vont dire, par exemple, si on travaille sur des drives. Je veux que la commande elle soit faite que si j'ai tous les articles, Et puis, tu as d'autres qui ont travaillé sur du retail, c'est-à-dire pour réapprovisionner des magasins. En fait, le magasin, quand il commande, je ne sais pas moi, 10 chemises et 14 pantalons, si tu n'as que 13 pantalons, ce n'est pas grave, il prend quand même les 13 pantalons. Mais tu vois, ça, c'est des petits détails. C'est-à-dire, tu as des clients qui veulent que, typiquement dans l'alimentaire, les articles lourds soient au fond et les articles légers au-dessus. Parce que si tu commences à mettre une bouteille d'huile sur les œufs, on risque d'avoir des problèmes. Tu en as d'autres qui s'en fichent. par exemple tu mets des vêtements tu peux les mettre dans n'importe quel ordre il n'y a pas de problème mais par contre ils aimeraient bien qu'on ne mélange pas les chemises avec les pantalons donc si on commence avec les chemises on fait que les chemises que les pantalons tu vois tu as toute cette gestion, logistique pour le coup de la connaissance logistique et de l'optimisation logistique parce qu'on a aussi énormément d'optimisation logistique dans quel ordre je fais mes requêtes tiens j'ai un client vip qui vient d'envoyer une commande il faut la faire de façon urgente, si toi tu es le client vip tu cliques, dans 15 minutes elle peut être prête. Mais pour ça, il faut être capable de réagir à cette urgence, d'être capable de réoptimiser en permanence ce genre de choses. Et c'est plus ça qui est complexe, en fait. Parce que nos robots, c'est toujours tous les mêmes. D'accord ? La forme de l'entrepôt est différente, mais finalement, on arrive à généraliser assez simplement. Par contre, ce qui est difficile et ce qui est très complexe à tester, c'est tous ces contextes logistiques. parce que tu fais une petite modification, il faut vérifier que ça continue à marcher dans tous les contextes logistiques. Donc, ce que je te disais, on a déjà des tests automatiques et puis après, à chaque release, on a une équipe de testeurs dédiés qui va faire des tests à la fois en simulation parce qu'on est capable de simuler entièrement nos systèmes. Et alors, en fait, ce qui est super sympa, c'est que quand on simule un système, finalement, on ne simule que les robots. Tout le reste, c'est le même applicatif qui est tourné. Et on simule, et dans la robotique, on simule en fait que les retours des capteurs. C'est tout. Tout le reste, c'est exactement le même logiciel qui tourne, que ce soit en simulation ou que ce soit en réel. Déjà, ça permet de tester plein de choses en simulation. Et après, on a des systèmes de test directement à Croix, là où on est. À côté de nous, il y a un système de test complet avec des robots qui tournent, dans lequel on est capable de le déployer en amont et de le tester énormément.

Bruno — Du coup, vu que tu testes uniquement les retours des robots ? Parce qu'on évoquait tout à l'heure que ton robot il est capable du coup de réajouter son trajet en fonction de ce qu'il voit parce qu'il patine un peu d'un endroit parce qu'il a une roue qui va moins vite que l'autre, au final tu considères est-ce que tu vas simuler uniquement ça les retours des différents capteurs parce que tu considères soit que le robot est suffisamment intelligent pour, suffisamment bien corriger son trajet pour dévier très peu, du trajet qui est prévu ou est-ce que c'est parce qu'au final les variations sont suffisamment faibles pour que les différences entre les tailles des roues l'adhérence et autres est suffisamment faible pour que, cette réalité terrain n'ait pas besoin d'être testée en tant que telle.

Sophie — Je dirais ni l'un ni l'autre en fait non, c'est justement le problème de la simulation quand tu stimules justement un robot c'est que la réalité physique sera toujours différente de ce que t'as simulé. Mais par contre, si ta feature c'était de l'optimisation sur la préparation de commandes ou sur la façon dont tu tries tes articles, t'as pas besoin de tester ça avec des vrais robots. Ou si ta feature, elle consistait à se dire si j'arrête un robot, je veux moins que ça cascade qu'avant, en fait tu t'en fiches aussi que ton robot il soit exactement à la position où il était et qu'il a réussi à corriger ou pas parce que ce que tu vas faire, c'est que tu vas simuler qu'il y a un robot qui s'arrête et que tu vas vérifier que ça s'étend moins qu'avant, qu'il y a moins de robots qui sont impactés. Mais du coup, tu peux faire énormément de tests en simulation parce que le fait que le robot se réadapte dans ces features-là, tu t'en fiches. Et l'autre problématique aussi, c'est qu'un système, ça coûte assez cher. On en a un pour faire nos tests. Il y a beaucoup de monde qui veut faire des tests dessus. Et du coup, il faut optimiser. Et tout ce qui peut se tester en simulé, on le teste en simulé. Mais après, on vérifie toujours, toujours, toujours avant chaque révise qu'on a une liste de tests à vérifier systématiquement pour vérifier qu'en réel, ça continue à marcher, y compris de la logique, du test bout en bout systématiquement. Et par contre si ta feature elle était sur le robot justement sur la robotique bah là t'es bien obligé de la tester en réel parce que justement t'as besoin du réel.

Bruno — J'aurais une autre question après sur, J'aurais une question sur quoi ? Bon, ce n'est pas grave, on reviendra tout à l'heure. Il y a une question dans le chat de Valkins. Ça prend combien de temps pour une installation, une mise en prod sur place ? Car a priori, on ne peut pas faire cohabiter les personnes et les robots, donc il faut interrompre la logistique pendant un certain temps. Donc, comment ça se passe, cette mise en place ?

Sophie — Alors, il y a deux choses. Déjà, pour répondre à ton timing, ça dépend de l'entrepôt. Parce qu'en fait, nous, on intègre, on ne vend pas que notre système Skypod. On peut l'intégrer dans un entrepôt complet. C'est-à-dire que nous, on va être intégrateur de solutions qui sont fabriquées par d'autres. Typiquement, un robot de dépalétisation ou de palétisation, etc. Donc, si on considère qu'il y a l'entrepôt complet avec le convoyage, etc., ça peut prendre jusqu'à six mois d'installation. Mais par contre, sur un petit système où on installe juste notre Skypod système, le plus rapide qu'on ait fait c'est 6 semaines pendant 6 semaines et donc ça c'est le temps d'installation c'est à dire qu'il n'y avait rien il y avait juste une dalle 6 semaines plus tard les robots ils tournent et ils sont en prod c'est quand même assez rapide, par contre ça empêche pas de continuer alors ça dépend, soit on a 2 types de, projets si tu as les projets où on est sur des entrepôts nouveaux donc là il n'y a pas de problématique de continuer la production qui était faite avant par des humains et on a des entrepôts aussi où on vient s'insérer dans un système existant où il y avait des humains avant ou alors où il y avait ce qu'on appelle des shuttles c'est-à-dire c'est des... Le système Shuttle, c'est vraiment de l'automatisation. Pour le coup, c'est des rails avec des ascenseurs, etc. Donc, c'est de l'automatisation, mais c'est très, très lourd mécaniquement, alors que nous, on apporte une solution qui est beaucoup plus légère. Dans ces cas-là, en fait, on va juste mettre du grillage, délimiter physiquement une partie et on est capable de continuer, enfin, de laisser la prod qui continue et nous, de mettre notre solution petit à petit dans l'entrepôt. C'est ce qu'il y a. Il y a pas mal de nos clients qui sont intéressés par ça. C'est qu'aussi, si nous on veut agrandir notre solution tu vois au début, typiquement t'es dans le e-commerce, tu sais pas trop ce que ça va être dans 5 ans donc tu te dis bah ouais mais je sais pas comment dimensionner parce qu'aujourd'hui j'ai besoin de, je sais pas moi, 30 robots et puis peut-être que dans 5 ans, mon activité elle aura fait un boom énorme et j'en aurais besoin de 100 mais j'ai pas envie d'en acheter 100 maintenant parce que j'ai pas les fonds, Ça, c'est pas grave, parce qu'on est capable, nous, avec un système qui marche, on construit notre autre système à côté et ça prend juste quelques jours. Une fois que l'autre est prêt, on le teste indépendamment et ça prend quelques jours pour les connecter. En gros, on enlève le grillage, on remet proprement, etc. On redéploie notre nouveau graph qui tient compte des deux. C'est parti.

Bruno — Et du coup, quand tu fais cette extension, t'avais un extenseur, un orchestrateur sur l'extension pour tester que ça fonctionnait bien. Et après, tu retires l'orchestrateur du nouvel environnement pour m'intégrer où tu gardes avec les deux orchestrateurs.

Sophie — Ah non, à la fin, tu n'as qu'un seul orchestrateur.

Bruno — Et du coup, si tu veux aller au-delà de cette limite de 200 robots, là, pour le coup, il te faut un deuxième orchestrateur qui va gérer une zone géographique particulière.

Sophie — Séparé. Vraiment, physiquement séparé.

Bruno — Et est-ce que du coup, tu as un orchestrateur d'orchestrateurs ?

Sophie — Alors, oui. C'est un autre de nos produits qui s'appelle Deep Sky, qui est là purement du soft pour le coup, qui est vachement intéressant, qui est un WES, alors c'est un Warehouse Execution System, donc dans le monde de la logistique il y a plein d'acronymes comme ça, alors lui c'est un orchestrateur au niveau entrepôt complet donc lui il est capable de faire bouger des charges, de faire bouger des tas de trucs sur du convoyage, d'interfacer avec d'autres robots, d'interfacer avec des machines de type, mesure de dimension avec des machines de type RFID, etc., et de s'interfacer avec nos systèmes. Et donc, lui, il vient se mettre entre le WMS, donc ça, c'est le Warehouse Management System, donc ça, c'est le client, lui, qui connaît ses clients finaux, qui connaît son stock, qui va nous envoyer tous ces ordres-là. On a notre DeepSky qui est au milieu, qui, lui, va gérer l'ensemble de l'entrepôt et qui, ensuite, va envoyer les informations qui l'intéressent à chacun de nos systèmes, chacun de nos astars, notre orchestrateur de robots.

Bruno — Ok. Passionnant. J'ai retrouvé une autre question que j'avais, c'est sur cette notion de mise en prod, mais de manière plus précise. C'est sur... Attends, parce qu'en fait il y a plusieurs aspects. Tout à l'heure tu nous as expliqué que tu as des clients où il y a des notions de priorité. Tu as des clients VIP, tu as des façons où tu veux ranger les commands, enfin bref. Tu as des techniques qui sont spécifiques. Ma question c'est à quel point est-ce que votre code, votre solution, répond en fait à toutes les problématiques versus est-ce que tu as du dev parfois très custom pour certains clients et du coup est-ce que chaque client a une code base, spécifique ou est-ce que tout le monde a la même et du coup en fait au final, même si je suis un vendeur de vêtements je peux gérer ma question de poids en mettant les vêtements les plus lourds au fond alors.

Sophie — C'est ça en fait je te remercie de cette question là ça fait partie des choses qui sont vachement intéressantes c'est que nous on vend un produit standard c'est-à-dire que. On est vraiment la boîte est découpée en deux la partie produit et la partie projet et la R&D, et la production c'est la partie produit c'est-à-dire que un robot quand il est designé il est designé pour aller chez n'importe qui d'ailleurs un client il n'achète pas des robots il achète un certain nombre de robots c'est-à-dire qu'on lui garantit juste qu'il va toujours avoir le même nombre de robots mais le robot qui est à un moment donné chez un client peut-être qu'on va le ramener pour de la maintenance préventive puis après il va aller à l'autre bout du monde le lendemain ça c'est possible, Donc les robots sont complètement standards, l'orchestrateur est aussi complètement standard et l'écran, parce qu'on a aussi de l'IHM pour l'opérateur pour indiquer ce qu'il doit faire, est aussi complètement standard. Il n'y a rien de custom là-dedans, tous les clients ont exactement la même chose. Et donc ce qu'on vend aussi c'est finalement dire quand un client nous demande une nouvelle feature finalement si on la développe on va en faire bénéficier tous nos autres clients, eux ils l'auront pas acheté mais à la prochaine mise à jour ils vont l'avoir quand même et ils vont avoir de l'optimisation, pas gratuite en fait ça fait partie de ce qu'on vend de notre solution on leur dit vous allez toujours être à jour on n'est pas à dire vous l'avez acheté dans une version et ça va être votre version et dans dix ans, ça va vous coûter très cher pour remettre à jour. En fait, on met à jour en permanence nos sites clients, y compris ceux qui sont en production, pour maintenir à peu près tous les sites au même niveau d'avancement.

Bruno — Et c'est à quelle fréquence ces mises à jour ?

Sophie — Alors ça va dépendre des clients. On essaie de les passer sur des versions stables assez régulièrement. Ça dépend. Tous les ans, à peu près, ils vont avoir... Alors, ils peuvent avoir... On a des versions stables plus souvent. Après, les clients n'aiment pas forcément tous les trois mois changer de version. Donc, ça dépend. Ça peut être au bout de six mois, ça peut être au bout d'un an, ça peut être au bout de deux ans. Mais on va essayer. On ne veut pas garder des vieilles versions. Donc, tous les sites qui sont dans des versions qui ont plus de deux ans, on les force à passer vers des versions plus récentes.

Bruno — Et cette mise à jour, ça se passe ? Comment il faut shut down everything ? Ça prend deux jours ou ça prend vingt minutes ?

Sophie — Alors, il faut shut down and racing, parce que si tu déploies des nouveaux softs, y compris sur les robots, il ne faut pas qu'ils soient en train de faire quelque chose, donc oui, on a besoin d'un temps d'arrêt, mais après, c'est pareil, tout ce travail-là, on a énormément automatisé le truc pour, déployer, enfin, on a un système de superviseur, enfin, on a, un serveur qui est un superviseur, qui lui, on va lui envoyer la nouvelle version, et lui, ensuite, il est capable de savoir ce qu'il y a sur le site et puis de pousser toutes les versions en dessous vers les bonnes machines qui ont besoin du bon soft et puis ensuite, chaque machine redémarre et c'est reparti, quoi. Ce qui va être long, ça va être plus la partie basse de données. Si tu commences à avoir des migrations de données, parce que tu as changé ton modèle ou parce que, tiens, cette colonne, elle était nullable et d'un seul coup, il te faut une valeur par défaut. Tu as changé un nom de setting ou ce genre de choses. Là, il faut migrer toutes les données et ça, c'est la partie qui est presque la plus longue. Mais ça se fait en quelques heures. En quelques heures, c'est OK.

Bruno — Du coup, en gros, on est sur une version majeure par an.

Sophie — Alors, on a plus de versions majeures. On a trois versions majeures. Deux à trois versions majeures par an. Mais tous les clients ne passent pas de majeures. Des fois, ils sautent une majeure.

Bruno — Parce que j'imagine qu'il y a quand même un... Entre le fait qu'il faille tout arrêter pour mettre à jour, le fait qu'il y a quand même un risque toujours à mettre à jour, qu'on est quand même sur des solutions qui en elles-mêmes coûtent cher. Mais si ça te bloque ta logistique pendant trois jours, ça te coûte vraiment très cher. J'imagine que vous avez du coup un process de validation ?

Sophie — Exactement, on a un process de validation et surtout on a des serveurs de pré-production. Pour chaque client ? Pour chaque client. Alors, non, pas pour chaque client, mais on va être capable de les, utiliser, on les vide et on remet la configuration du client. Avant de déployer chez un client, on teste sur serveur de pré-production dans la configuration du client, on fait un backup de leur base, on récupère leur base et on vérifie que tout marche, si tu veux, d'abord en pré-production avant de déployer pour vérifier que tout se passe bien, que tout va bien s'installer correctement, que quand on va redémarrer ça va bien vouloir redémarrer qu'on est capable de relancer de la préparation de commande, après on a des systèmes de simulation aussi, de préparation de commande qui vont simuler les clics de l'opérateur, justement pour faire cycler pendant une heure, pendant deux heures pour voir si tout se passe bien, Est-ce que.

Bruno — Question du coup dans le chat toujours de Valkans ? Est-ce que ça arrive qu'une mise à jour, surtout concernant les pods, se passe bien sauf à un endroit, par exemple à cause d'un défaut du sol qui entraînerait une surcompensation ? Est-ce que tu as déjà eu le cas d'une mise à jour qui va en fait capoter parce qu'il y a un cas particulier chez un client, il ne faut pas en pousser plus de lumière, où en fait ce cas très particulier physique entraîne une surcorrection dans le nouvel environnement et du coup en fait...

Sophie — Non, ce n'est pas physique. Les problématiques, c'est plus sur le contexte logistique, sur le process logistique du client qui est différent d'un client à l'autre où on ne va pas avoir pensé que tel client l'utilise de telle façon. On a amélioré pour un, mais en réalité, on a dégradé pour un autre. Ça va être plutôt là-dessus. Mais après, sur du physique, c'est assez rare. De toute façon, la mise à jour, ce n'est pas parce qu'elle rate chez un client. Si elle se passe moins bien chez un client, elle peut quand même se passer très bien chez plein d'autres clients. Ça n'empêchera pas de déployer chez les autres clients.

Bruno — Il y a un contexte spécifique qui fait que chez un.

Sophie — Client il y a un truc, c'est toujours pareil dans les tests, tu testes ce que tu as pensé à tester si tu tombes sur un cas auquel tu n'as pas pensé, tu ne l'as pas testé et là c'est du pile ou face c'est toujours le même problème.

Bruno — Je vois que ça fait déjà une heure qu'on discute. Je pense qu'on a quand même fait un joli tour. Pour terminer, j'aimerais du coup parler de la notion de recrutement. Déjà, vous êtes combien dans l'équipe aujourd'hui sur ces différents sujets ? On sent qu'il y a quand même un niveau d'exigence assez fort sur l'Apple. On a parlé de la performance, on a parlé de la qualité, que clairement, tu ne peux pas déployer du code qui fonctionne dans 20% des cas ou même dans 80% des cas parce qu'en fait, ça peut coûter trop cher aux 20% restants. Donc, c'est quoi la taille de vos équipes et sur comment est-ce que vous recrutez, pour être sûr de maintenir ce niveau d'exigence ?

Sophie — Alors, déjà au niveau Exotec, Exotec, c'est une boîte qui double ses effectifs tous les ans depuis le début. Donc là, aujourd'hui, on était 800 et l'objectif, c'est d'être... Aujourd'hui, à date, on est 800 à peu près, partout dans le monde donc on est sur les Etats-Unis on est à Atlanta on est à Munich on est à Tokyo et on est à Croix à Lille en France 800.

Bruno — Sur le dev ?

Sophie — Non 800 sur l'ensemble de la boîte sur la partie, dev alors après sur la R&D t'as du dev mais t'as pas que du dev t'as aussi la méca et puis l'électronique sur le dev on doit être 150 à peu près ok aujourd'hui on est tous à Croix et alors là grosse annonce on ouvre un site à Lyon parce que, comme tu dis il faut recruter, l'objectif c'est aussi de recruter énormément de développeurs, et on a un peu fait le tour des gens qui sont dans le nord, parce que Croix c'est à côté de l'île et ça fait peur, l'île il fait froid, tout ça en réalité non, c'est super sympa mais voilà, et donc on ouvre aussi un site là, à partir de septembre on va avoir un site de développement, vraiment orienté sur la R&D soft à Lyon aussi. Donc voilà, faut pas hésiter si jamais il y a des auditeurs qui sont intéressés et qui avait un petit peu peur de monter dans le nord, Lyon, il fait un peu plus chaud. Et dans le process de recrutement, effectivement, on a vraiment besoin d'une vraie qualité. Donc, on a des tests techniques. Ça passe par trois étapes, le recrutement. Il y a un entretien RH assez classique, un test technique fait par quelqu'un qui est en raidé. J'en fais passer assez régulièrement des tests techniques. Et puis après, il y a l'entretien avec le manager. Et c'est vrai que sur nos tests techniques, on a bien... enfin, moi, sur ceux que j'ai fait passer, j'ai à peu près 50% de passes, 50% de fails, quand même. Donc, c'est des tests techniques qui sont assez exigeants, parce que derrière, on veut de l'autonomie, on veut une capacité à apprendre, une capacité à s'intéresser au-delà de... Enfin, clairement, à Exotec, on n'est pas des devs exécutants, jamais. Y compris le plus junior des devs, il n'est pas exécutant, il a une vraie responsabilité, il doit amener ses futurs en entier, le designer, développer, etc. Alors, il est aidé, mais il ne faut pas qu'il soit non plus tout le temps à attendre la suite.

Bruno — Et sur l'onboarding, du coup, ça se passe comment ? Vous avez une target, vous dire, à ta troisième semaine, tu dois shipper une feature ?

Sophie — Alors non, c'est pas aussi strict que ça, parce que ça dépend un petit peu du domaine sur lequel il arrive, sur quel poste il arrive, mais on a, alors, à Exotech, tout est exo quelque chose. Il y a une vraie culture d'entreprise là-dessus et donc on a un exo-brevet c'est-à-dire qu'on va avoir une des features on va dire bah écoute ce truc-là c'est un petit peu ton test d'entrée, c'est là-dessus qu'on va identifier si c'est ok ou pas pour nous au bout des trois mois de la période d'essai bon après pour le côté fun moi mon exo-brevet je l'ai fini deux ans après, parce qu'en réalité on m'a donné d'autres trucs à faire puis d'autres trucs à faire qui étaient vachement plus urgents parce qu'à ce moment-là on avait d'autres problématiques et puis à un moment donné on a dit Au fait, ce truc-là, il faudrait que tu le finisses. Donc voilà, c'est aussi... C'est aussi du feeling. Tu vois bien si quelqu'un convient dans une entreprise assez rapidement. En réalité, en trois mois, tu as quand même assez vite vu si la personne, elle convient en termes de façon de travailler, puis en termes d'état d'esprit, etc.

Bruno — Oui, je vois.

Sophie — Et si je peux me permettre aussi sur le recrutement, on a un autre truc. Alors, ce n'est pas tout à fait du recrutement, mais on fait un hackathon. On a l'hackathon exo-légende.

Bruno — Exo-quelque-chose encore.

Sophie — Exo-quelque-chose, évidemment. On est des exo-people. Enfin, voilà, il y a tout qui est exo. Mais l'exo-légende, c'est un hackathon robotique. On a eu notre première édition cette année, en avril. Ça a super bien marché. Il y avait 130 codeurs. Et l'idée, c'était... Ils sont arrivés avec juste leur ordinateur. Et on leur a donné des petits robots à monter. Donc, avec le plan, des robots en bois, en mode puzzle. Une petite carte électronique. Et puis, ces robots étaient dans un labyrinthe et devaient gagner des points, combattre les autres, etc. Ça a été trois jours absolument extraordinaires. Et on remet ça l'année prochaine, puisque ça a super bien marché. Donc, c'est pareil, il ne faut pas hésiter à venir participer. C'est ouvert à tout le monde. Ce n'est pas ouvert que aux étudiants. C'est vraiment ouvert. Et ce n'est pas ouvert qu'aux devs. Enfin, il faut savoir développer, mais ça peut être juste des gens qui font du dev chez eux, dans leur garage. L'an dernier, on avait un comptable qui disait, mais moi, j'adore devs. Alors, mon fils, il est en école d'ingénieur. On est venus tous les deux. Voilà, super.

Bruno — C'est vachement bien marché. Du coup, ça me fait penser à un autre truc. Alors, j'ai pas les noms exacts. J'ai découvert ça la semaine dernière, je crois. Donc, c'est vraiment la sérendipité à plein. Il y a une compétition chaque année où des gens qui font des micro-robots qui doivent résoudre des parcours. T'as déjà vu ça ou pas ?

Sophie — Ouais, j'ai déjà vu ça, oui.

Bruno — Le truc de souris. Et du coup, ça me ramène à plein de questions qu'on a vues ensemble. Parce que du coup, j'ai un reportage là-dessus qu'on parle de manière assez détaillée et qui parle notamment de l'évolution du truc. Donc, en fait, l'arène c'est un labyrinthe qui t'est révélé au début de la compétition, et t'as le droit je crois à 30 minutes de code sur ton robot avant de le mettre dans le truc et l'idée c'est d'avoir une souris qui va trouver t'as 3 tests pour trouver le trajet le plus rapide et du coup trouver le chemin le plus rapide dans ce labyrinthe, et il expliquait notamment que, il y a eu des notions de palier dans la progression du concours parce que du coup pendant un moment les gens ont d'abord juste cherché à faire un robot qui va, réussir à avancer le plus vite possible après il y en a qui ont réussi à trouver que quand t'as, des virages comme ça en fait si tu fais un robot qui fait du coup des virages alors je suis dosé parce que c'est un podcast en fait donc faire des virages comme ça c'est pas ouf mais c'était une succession on va dire de chicanes à l'ancienne le robot il faisait que des virages à angle droit et en fait il y a un jour un mec qui a débarqué avec un robot qui faisait la chicane en diagonale qui du coup a optimisé son temps de ouf et en fait il y avait un plafond de chrono avant l'arrivée de cette diagonale qui du coup après a fait exploser les temps il y en a qui sont arrivés après. Où sur une première exploration ils font quasiment tous les trajets ils ont optimisé la manière dont les trajets sont découverts pour réussir à trouver, il y a le trajet le plus court mais c'est pas forcément le trajet le plus rapide parce qu'en fait selon la capacité d'accélération de ton robot, et du coup ma question c'est est-ce que Exotec vous participe à ce genre de truc est-ce que ça aurait du sens que vous participiez alors certes vous avez des robots qui sont beaucoup plus gros mais au final vous avez quand même une expertise assez forte sur ce genre de choses peut-être.

Sophie — Qu'il y en a qui participent d'un point de vue personnel je suis pas au courant là dessus mais effectivement c'est exactement des problématiques qu'on a parce que le nombre de virages que t'as dans un trajet, tu serais dans un graphe de type Manhattan absolument une grille avec absolument tout disponible en fait pour aller d'un point A à un point B t'as plein de chemins, mais t'en as deux qui sont beaucoup plus rapides c'est eux qui n'ont qu'un seul virage, Et pourtant, en distance, tous tes chemins font exactement la même distance. Donc oui, on a des problématiques de ce type-là. Et dans nos algos, on optimise ce genre de choses justement par rapport aux virages. Parce que c'est pas... Des fois, c'est intéressant d'aller prendre des virages parce que t'as besoin de ralentir. Parce que finalement, avec les robots qui sont déjà là, voilà. Et parfois, si ton robot, il est tout seul, non, il ne faut pas qu'il prenne des virages. Enfin, au moins, impossible. Parce qu'effectivement, en temps, prendre un virage, c'est toujours plus pénible.

Bruno — Tu connais le GPS d'UPS ?

Sophie — GPS d'UPS non ?

Bruno — UPS qui est du coup un transporteur ils ont un GPS quand ils font le parcours de leur camion de livraison ils ont un parcours qui ne prend que des virages à droite.

Sophie — Pour optimiser.

Bruno — Pour optimiser. Il y a plusieurs choses. Parce qu'en fait, quand tu prends un virage à gauche, tu dois traverser le sens inverse. Et donc, en général, tu t'arrêtes. Donc, tu perds du temps. Tu consommes de l'essence. C'est hyper accidentogène. Donc, tu prends un risque plus important de porter un camion rempli de trucs qui se fait renverser. Et il y a aussi le fait qu'en Amérique du Nord, quand tu tournes à droite, tu n'as pas besoin d'attendre que le feu soit vert. C'est assez souvent.

Sophie — Oui, tu as une priorité.

Bruno — Tu peux passer, même si le feu est rouge, si tu tournes directement à droite. Et donc, du coup, ils ont des chemins qui ne font que des virages à droite parce qu'en fait c'est beaucoup plus rapide, ça consomme moins d'essence, même si le trajet est plus long le trajet plus long en distance c'est pas forcément le plus lent c'est.

Sophie — Malin en fait il faut trouver les petits trucs adaptés à ton besoin et ton application.

Bruno — On n'y pense pas toujours merci beaucoup Sophie pour cette discussion j'aurais donné la question pour toi, les questions rituelles du podcast, la première c'est est-ce qu'il y aurait une ressource que tu souhaiterais recommander à tout le monde.

Sophie — Une ressource pas du tout tech c'est une série de livres que j'adore qui s'appelle La Tour Sombre c'est de Stephen King c'est une espèce d'épopée, à moitié western, fantasy, science-fiction horreur, c'est un petit mix de tout ça, et c'est une espèce de 4 initiatiques sur 7 ou 8 bouquins qui sont assez extraordinaires que Stephen King a écrit en plus de 30 ans au total entre la première et la dernière c'est un livre que j'adore et que je recommande alors le film pas trop mais le livre à fond.

Bruno — C'est avec Idriss Elba je crois le film.

Sophie — Exactement, mais en fait ils n'ont pas repris l'histoire du livre, ils se sont positionnés après le livre.

Bruno — Oui ça c'est les choix.

Sophie — Je pense que c'était trop compliqué de faire le livre en réalité.

Bruno — On mettra du coup bien évidemment un lien en description, La dernière question, ce serait la question rituelle du podcast, et la plus importante, très certainement. Est-ce que tu es plutôt espace ou tabulation ?

Sophie — Tabulation.

Bruno — Merci beaucoup, Sophie.

Sophie — Merci Bruno.

Bruno — Et hop, on tourne la caméra. Et merci à tous d'avoir écouté cet épisode jusqu'au bout, passionnant, du coup un petit peu plus long que d'habitude, mais c'était passionnant. On aura encore plein de questions. C'était absolument top. Merci beaucoup pour cette plongée dans ces sujets-là. Je vous remercie à tous toujours de partager ce podcast autour de vous. Je vous souhaite une très bonne fin de semaine. Je vous dis à la semaine prochaine. Et d'ici là, codez bien !