Bruno:
Automatiser la donnée, c'est un peu comme bricoler dans un immense jeu de tuyaux. On prend un truc d'un côté, on le transforme, on le balance ailleurs, et quand ça déborde, tout le monde va chercher un peu d'où vient la fuite. Sauf qu'en 2026, les tuyaux sont devenus un vrai millefeuille, avec des bâches, du real-time, de la big data, du YAML, du Java, du Quarkus, et chaque client veut son propre robinet personnalisé, parfois même avec une pincée d'IA dans le pilotage. On en vient à rêver d'un orchestrateur universel, capable de distribuer la donnée partout, de gérer l'hétérogénéalité et de survivre à chaque nouvelle techno shiny. Mais alors, ce chef d'orchestre peut-il vraiment exister ? Peut-on vraiment tout centraliser sans transformer l'usine à gaz en usine à problème ? Et surtout, si on ajoute des LLM dans le mix, aura-t-on une symphonie ou une cacophonie ? Pour répondre à ces questions d'orchestration, je ne reçois pas Stanislas Lefort, mais il s'est manié la baguette. Loïc, bonjour.
Loic:
Bonjour.
Bruno:
Alors Loïc, est-ce que tu peux te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?
Loic:
Bien sûr. Je m'appelle Loïc Mathieu. Je suis Lead Software Engineer à Kestra Technologies. J'ai 22 ou 23 ans d'expérience dans le développement, principalement développement backend Java. J'ai une expertise sur la JVM, le fonctionnement du runtime de Java. Une petite passion pour la performance, on en a parlé. Donc bon, je suis passé, j'ai commencé dans une SS2I à l'époque, ce qu'on appelait. Ensuite, j'ai bossé chez Kiabi en tant qu'architecte logiciel pendant 9 ans. Après, j'étais chez Zenica pendant 3 ans, 5 ans, pardon. Donc j'ai fait du consulting dans beaucoup de sociétés. Donc j'ai vu beaucoup de choses différentes. Et depuis trois ans, je suis dans une startup française qui développe une plateforme d'orchestration, Kestra.
Bruno:
Quand on parle d'orchestration de données, je ne sais pas pourquoi j'ai eu cette réflexion ce matin même. C'est qu'en fait, on... Je pense qu'il y a quand même une corrélation avec l'arrivée du cloud où d'un coup, on s'est retrouvé avec des ressources absolument illimitées. Enfin, avec une impression de ressources illimitées. Et qu'on a commencé effectivement à engranger énormément de choses. On a eu l'arrivée du cloud et on a eu peu de temps après l'arrivée du big data. Parce qu'en fait, j'ai l'impression qu'on a commencé à accumuler énormément de choses. Et donc, en tout cas, moi, c'est comme ça que je comprends l'orchestration de la donnée. C'est qu'au bout d'un moment, tu as tellement de données qui transident dans tous les sens que il faut que tu aies qui a quand même un outil qui centralise un peu tout ça.
Loic:
Ouais alors ça va plus loin parce qu'il y a les données, alors nous on n'est pas que données, je reviendrai plus tard, mais il y a aussi le fait que c'est les sources c'est le nombre de sources quoi, c'est pas juste qu'on a de plus en plus de données, c'est qu'aujourd'hui c'est assez classique dans une entreprise de s'interconnecter avec 50 systèmes SaaS, tu vois, parce qu'il y en a plein, c'est pas cher, ou on en reste un, moi quand je bossais chez Kiabi, on testait des nouveaux partenaires marketing, mais tous les mois. Enfin, il y en avait 60, 70 et tous les mois, il y en avait qui rentraient et qui sortaient. Donc, à chaque fois, il faut s'interfacer avec tous ces partenaires et cette glu à chaque fois aller refaire des batchs ou des flux sur des USB ou des choses comme ça, c'est technique. Il n'y a pas vraiment de plus-value. Et donc, c'est de ce constat, c'est un peu de ce manque que sont arrivés les orchestrateurs de données. Et d'ailleurs, c'est exactement pour ça qu'est arrivé Kestra. Au départ, Kestra a été créée chez Leroy Merlin. donc c'est ce qu'on appelle notre founding partner. Design partner pardon je dis n'importe quoi et donc c'était un besoin de pouvoir aller orchestrer toutes les sources de données toutes les pipelines d'injection de données de Laura Merlin pour l'équipe Data la plateforme Data de Laura Merlin, et maintenant on a évolué sur une plateforme d'orchestration universelle puisqu'on On n'est plus du tout spécialisé sur la donnée. On est capable de faire plein d'autres choses. Aujourd'hui, Onquestra va être utilisé pour l'ingestion de données, des pipelines de data, mais aussi pour tout ce qui est orchestration d'infrastructures, pour tout ce qui est business workflow. Pour tout ce qui est ITSM, qu'on utilise aussi beaucoup. Tout ce qui est support management, des choses comme ça. Donc on a un système de plugins et nos plugins touchent vraiment tous les domaines différents et c'est pour ça qu'on peut tout orchestrer et bien sûr, Les workflows, dire. Puisqu'on a pas mal de tâches qui sont spécialisées là-dessus. Donc c'est parti d'un besoin, peut-être qui au départ était fort la data, mais qui en fait se retrouve globalement dans une entreprise. Aujourd'hui, il y a plein de systèmes qui orchestrent des workflows. C'est-à-dire que quand tu as une crontable qui lance des batchs, c'est un système qui orchestre des workflows. Des workflows avec un ou plusieurs batchs. Tu as un système qui va aller générer des tickets, s'interfacer le ticket pour aller envoyer sur Slack des notifications, tout ça, c'est du workflow. La CICD, c'est du workflow. Et donc, généralement, les entreprises vont avoir 10, 15, 20 systèmes de workflow. Le plus visible est peut-être celui qui est pour les ingestions de données de pipelines de données ou d'IA parce qu'aujourd'hui on parle beaucoup d'orchestration d'IA tous les gros providers d'IA commencent à intégrer des systèmes de workflow à l'intérieur de leurs outils, mais nous de ce fait on a vraiment une plateforme unifiée pour que tous vos workflows puissent les faire de la même manière, on a choisi d'être agnostique du langage, c'est-à-dire que le workflow tu le définis en YAML, Avec un système de plugin qui permet de tirer parti des 1400 tâches qu'on t'offre. 1400 plugins qui sont dans la plateforme. Mais tu peux créer tes propres plugins. Pour aller enrichir la plateforme. Et tous tes plugins. J'y reviendrai plus tard. Mais toutes les parties de l'orchestrateur sont des plugins et peuvent être customisées ou enrichies. Et donc on va vraiment être capable de traiter tous les types de workflow. Et on offre vraiment une plateforme, c'est-à-dire que tu as centralisation des logs, centralisation des exécutions, pouvoir faire le rejeu, la gestion des erreurs, l'alerting, la notification, gérer l'observabilité, les traces, les métriques. Et puis, bien sûr, avoir tout l'accès aux gouvernances pour les entreprises. Donc on ne parle pas juste de l'authentification le single sign-on mais pouvoir aussi dire j'ai une équipe qui travaille sur ses propres workflows qui sont dans un namespace, une autre équipe qui n'a pas accès au namespace, des gestions multi-turn-on pour avoir des ensembles de namespace sur chaque équipe, des interactions avec les ITP classiques tout ce qui est audit log traçabilité, enfin voilà tout ce qui est nécessaire pour aller scaler, parfois on dit on est un peu un control plane d'orchestration et pas juste une plateforme d'orchestration.
Bruno:
Oui parce qu'effectivement l'idée c'est de pouvoir aller orchestrer en fait tout ce qui est entre guillemets orchestrable mais ce qui veut dire, enfin la question que je me pose c'est que un pipeline de données versus une CI si je prends quelques exemples dans ce que tu as cité il y a quand même des, pas mal de paramètres ou de contextes ou d'éléments qui me semblent très différents entre les deux, est-ce que ça veut dire que pour pouvoir orchestrer ces deux systèmes là et tous ceux que tu as cités de la même manière en fait t'es obligé de rajouter une abstraction sur tout ça en plus pour justement pouvoir considérer tout ça comme étant au final juste une exécution avec un input et un output de manière assez...
Loic:
Alors effectivement un workflow il a des inputs. Un ensemble de tâches et un ensemble de triggers. C'est les briques de base. Donc, les tâches, c'est les tâches du workflow. Chez nous, ça s'appelle des tasks. Et un workflow, ça s'appelle juste un flow. Donc, je vais utiliser plutôt flow dans le reste du déroulé. Et les triggers, en fait, c'est une manière de déclencher l'exécution. Alors, bien sûr, depuis l'API, parce qu'on est API First, donc tu peux tout faire sur l'API. Depuis l'API, tu peux déclencher des exécutions. Mais souvent, en production, tu vas avoir des triggers. alors tu peux en avoir des triggers de type webhook comme ça c'est vraiment une URL non authentifiée avec une clé dedans, mais tu peux aussi avoir des triggers de type schedule, le plus classique et nous c'est tu mets une crontable en fait c'est très simple, mais aussi on a des triggers qui sont événementiels. J'ai une donnée sur la base de données soit en CDC soit avec une requête, une requête de polling un message qui vient dans un broker et ainsi de suite, la petite différence c'est que nous on fait et le micro-batch et le real-time c'est à dire que par exemple sur une base de données ou sur un broker de messages tu pourrais dire je vais poler une table toutes les minutes et je remonte toutes les informations, Dans 80% des cas, c'est ce qu'on va vouloir faire sur de l'orchestration, surtout si c'est de l'orchestration de data, parce que ta table, tu vas aller déclencher un pipeline toutes les heures, peut-être, et puis traiter un million de lignes, plutôt qu'aller le déclencher un million de fois par heure, en temps de workflow. Mais on peut aussi faire du near real-time, parce que le real-time, c'est encore autre chose, avec des real-time triggers. Et les real-time triggers, eux, ils vont dire, pour chaque message, je déclenche une exécution. Pour chaque ligne envoyée via du change data capture dans ma base de données, je déclenche une exécution. Donc on fait les deux types de triggers. Donc ça, c'est un peu spécial. Ce qui veut dire que le surcoût d'une exécution sur un workflow, il ne faut pas qu'il soit trop gros. On rejoint les discussions de performance.
Bruno:
Mais donc, comment tu gères cette, différence, cette disparité entre tes différents workflows ? Est-ce que tu es obligé d'ajouter une abstraction au sein de Kestra pour pouvoir du coup adresser ces différents flux ?
Loic:
C'était ta question, je m'en rappelle, merci.
Bruno:
Mais en fait, les éléments que tu as donnés en plus.
Loic:
Il fallait que je présente un peu Kestra. Donc, ce qui se passe, c'est que nous... Rentre dans notre modèle. Donc on a un modèle, chaque tâche a toutes ses propriétés. Une tâche pour aller créer une VM, elle va avoir une centaine de propriétés. Une tâche pour aller charger de la donnée depuis une base de données, moi généralement, on sait la connexion à la base de données, ce n'est pas beaucoup. La différence, ça va être que une tâche qui va faire une VM, il va te remonter l'information au bout de trois minutes comme quoi la VM est créée. Une tâche qui va traiter de la donnée, elle va remonter de la donnée qui nous va être sérialisée au format Ion. Je pense que grosso modo c'est du JSON simplifié et plus fortement typé on a des dates en Ion par exemple, et stocké dans notre internal storage c'est une abstraction sur du storage généralement du storage d'object tu peux lancer sur ton file system si tu veux mais c'est uniquement pour les tests, et donc la différence c'est vraiment ça quand c'est du data ils vont utiliser des fonctionnalités spécifiques de Kestra pour gérer de la donnée et un ensemble de tâches qui vont être dédiées à gérer de la donnée, des tâches de mapping, et ainsi de suite et quand c'est de la VM, on va plutôt utiliser des tâches toutes faites sur étagère, pour du data aussi, ce qui est très très classique c'est d'aller utiliser des tâches de script donc on supporte une quinzaine de langages de scripting, on isole tout dans des dockers donc pour du scripting on démarre un docker et on lance le script, donc du Python même je crois qu'on peut faire du PHP du C, du Java mais généralement on va utiliser des langages de script donc.
Bruno:
Chaque flow va générer son propre conteneur pour que toute l'exécution soit du coup isolée.
Loic:
L'exécution de la tâche donc comment Estra fonctionne chaque tâche va être exécutée directement dans un compétent qu'on appelle le worker c'est lui qui va exécuter les tâches la tâche c'est une tâche java, donc Estra est codée en java et on a des tâches de type script qui eux vont permettre d'exécuter un script donc on pense vraiment, j'ai un script Python qui est dans mon workflow. Et on va avoir un système où on va pouvoir lui passer les fichiers, Et récupérer des fichiers qui sont générés. Et donc après, tout est automatiquement transféré dans l'internal storage. C'est transparent pour l'utilisateur. En fait, il dit juste, j'ai ce fichier en entrée là et ce fichier en sortie là. Et on démarre un conteneur Docker. On copie le fichier, on exécute le script et on prend les fichiers en sortie. Alors, je dis Docker parce que c'est ce qu'il y a par défaut. Mais il faut savoir que les scripts, les tâches de type script, elles utilisent ce qu'on appelle un taskrunner. C'est encore un plugin. donc il y en a deux en open source qui sont Process et Docker Process, bon c'est Process sur la machine si tu veux que ça soit très rapide, tu t'économises la petite seconde nécessaire pour démarrer ton conteneur mais bon ça s'exécute sur ta machine après c'est à tes risques et périls donc par défaut c'est du Docker et dans la version d'Enterprise on propose du Kubernetes ou des runners dans les clouds donc tu peux directement aller runner ton script, sur du sur du GCP par exemple C'est ce que font certains de nos clients qui ont des gros batchs qui vont avoir des scripts qui vont traiter des gigabytes de données via du cloud batch.
Bruno:
C'est-à-dire que si je comprends bien, dans la version de base, l'ensemble des flows sont exécutés dans le contexte de Kestra. Mais dans une version d'entreprise, du coup, tu peux le runner dans ton propre cloud.
Loic:
En fait, c'est vraiment les tâches de type script, parce que toutes les autres tâches, c'est beaucoup plus rapide de l'exécuter. Quelle est une tâche qui va créer une VM en VMware, par exemple ? Il n'y a aucun intérêt de l'isoler dans un container Docker. Il n'y a aucun intérêt normalement, mais on sait qu'on a des grandes entreprises parfois qui préfèrent avoir des contextes ultra isolés. Donc sur la version 2.0, on est en train de voir pour pouvoir justement toutes ces tâches, qui ne sont pas des tâches de type script, mais qui s'exécutent dans un worker, pouvoir les isoler elles-mêmes. Donc un espèce d'avoir un tâche-corner spécifique pour toutes les tâches qui permettent grosso modo de lancer un worker juste pour ta tâche et de l'arrêter. Donc ça c'est vraiment pour des grandes entreprises beaucoup dans le milieu de la finance où ils ont des besoins d'avoir des ségrégations d'exécution de workloads très spécifiques.
Bruno:
Du coup toutes ces tâches non scripting elles sont faites en YAML directement dans l'enquestra.
Loic:
Tu les définis en YAML et nous c'est exécuté dans le worker c'est désérialisé dans une classe Java et le code est exécuté.
Bruno:
Et donc sur ces vous ne faites pas que de la data mais j'imagine que c'est utilisé principalement pour la data ou même pas spécialement ?
Loic:
Non, alors c'est vraiment ce que j'expliquais, c'est qu'au départ ça a été développé pour la data, mais en fait comme le moteur est universel et basé sur du YAML, il touche tout le monde. Il y a beaucoup d'orchestrateurs de données spécifiquement qui sont codés en Python. Ils sont codés en Python et ils t'obligent à écrire en Python. Nous on est codés en Java et comme on est en YAML, tes scripts tu peux les coder en le langage que tu veux. Et donc, on a beaucoup d'utilisateurs qui ont commencé à nous utiliser, entre autres sur la partie infrastructure. Et c'est très intéressant parce qu'on ne l'avait pas vu venir. D'un seul coup, sur notre Slack, il y a plein d'utilisateurs qui commencent à nous dire « Ah, j'ai tel problème avec vos tâches ansibles. » Ah oui, c'est vrai qu'on a des tâches ansibles. Je ne pensais pas que quelqu'un nous utiliserait. Et puis, est-ce que ce serait possible de supporter Proxmox ? Et en fait, on s'est aperçu qu'il y a plein de gens qui nous utilisent. Alors, il y a des gens qui nous utilisent pour orchestrer leur homelab, mais il y a aussi des gens vraiment qui nous utilisent pour remplacer un non-cibel tower par exemple pour orchestrer de l'on-cibel et c'est là on a vu qu'il y a énormément de use cases autour de l'infrastructure peut-être parce que YAML, ils aiment bien ça dans l'infrastructure ou peut-être juste parce qu'on a des fonctionnalités qui matchent et qu'on comble un vide, et après dernièrement on a aussi vu des gens qui nous utilisaient sur du process métier ou pour aller orchestrer des workflows avec des human tasks à l'intérieur ou des choses comme ça, donc on est utilisé en fait, sur des use cases très très très différents.
Bruno:
En général, quand on a jusqu'à ce point très différent qu'Hipop, vous avez une version open source qui est disponible ?
Loic:
Oui, bien sûr.
Bruno:
D'accord, ok.
Loic:
Avec tous les plugins. J'ai cité les quelques plugins Taskrunner qui sont en Enterprise, mais grosso modo, 99% des plugins sont en open source. En Enterprise, on a quelques plugins sur des technos ultra, que c'est très très grande entreprise, par exemple sur du Salesforce ou des choses comme ça. Qui sont en enterprise mais sinon 99% de nos plugins sont en open source.
Bruno:
Ça explique pourquoi il y a des gens qui l'utilisent on va dire de manière un peu, annexe mais au final c'est ce qui vous a permis de découvrir ces usages différents donc l'idée c'est d'en faire un orchestrateur capable de tout orchestrer, et d'orchestrer du coup peut-être même de se retrouver à orchestrer des orchestrateurs parce qu'il y a quand même des boîtes qui ont aussi déjà des orchestrateurs qui sont en place alors.
Loic:
Ça c'est marrant que t'en parles parce qu'on a travaillé sur des plugins pour s'interfacer avec d'autres systèmes. Alors, parfois, des systèmes qui sont des orchestrateurs ou des systèmes qui sont un peu entre les deux, comme DBT, et on a un plugin Airflow, on a des plugins autres. Et en fait, ça permet d'orchestrer des orchestrateurs, comme tu le dis, mais ça permet aussi de faire de la transition d'un orchestrateur à l'autre. C'est-à-dire que, je ne sais pas, tu connais le Strangler Fig Pattern.
Bruno:
Non.
Loic:
Tu pourras aller lire, il y a un article de Martin Foller qui en parle. Donc c'est une technique pour passer d'un système legacy à un nouveau système sans tout casser. Et donc, si, par exemple, tu es sur Airflow et que tu veux migrer sur Kestra, au lieu de te dire, je vais faire un projet de six mois pour aller prendre tous mes workflows dans Airflow et les réécrire en Kestra, tu fais ce qu'on appelle un Strangler Fig. C'est-à-dire que Strangler Fig, c'est le figuier qui a une capacité d'étrangler d'autres arbres avec ses racines, avec ses liens, je crois. Et donc tu dis maintenant tout le monde bascule sur Kestra et tous les flows Airflow on les appelle depuis Kestra et comme ça petit à petit on peut décommissionner les flows Airflow en les recodant en Kestra mais on n'a pas besoin de tout faire pas besoin de faire de Big Bang puisque la première étape c'est juste j'ai un flow Kestra avec une seule tâche qui est l'appel de mon flow Airflow donc ça je trouve que c'est intéressant comme pattern mais.
Bruno:
Ça nécessite quand même de payer vous avez une version open source j'entends mais du coup tu as beaucoup de contextes où tu peux pas te permettre de payer les deux licences en même temps donc il faut que tu fasses un choix.
Loic:
Bien sûr mais les transitions c'est toujours complexe de toute façon.
Bruno:
On est aussi dans un monde où les données viennent de tellement de sources différentes et qu'elles sont aussi très différentes les unes des autres c'est aussi un vrai sujet sur les orchestrateurs c'est comment tu gères des données différentes. C'est une approche que vous avez choisi de résoudre comment ?
Loic:
Alors nous, on la résout principalement en offrant des tâches qui permettent de transformer tout type de données vers notre format pivot qui est le Lion. Donc en fait, vraiment, toutes les tâches qu'Estra vont comprendre Lion. Et donc si tu veux gérer un autre format de données, on va te conseiller de le mettre en Lion. De toute façon, comme on a des tâches de type script, si tu ne veux pas passer en Ion parce que ton fichier est trop gros, tu peux toujours débrayer sur du scripting. C'est aussi un peu notre force, c'est que comme on a un scripting qui est capable de faire tout type de données, tu n'es jamais vraiment bloqué. Mais sinon, on conseille vraiment de tout basculer sur le format native Ion.
Bruno:
Mais là, du coup, c'est que tu parles de... Parce que qui dit format Ion, c'est un format qui est quand même un peu plus typé. Donc ça veut dire aussi des données qui sont très structurées parce qu'on a parfois des données qui sont non structurées ou structurées de manière différente, je pense par exemple tu as la différence de structure entre ta base relationnelle Postgres, et une base vectorielle tu commences à être dans des schémas qui sont un petit peu différents, comment est-ce que tu peux du coup avoir des flux, qui s'adaptent aussi bien à l'un qu'à l'autre ?
Loic:
En fait là c'est le rôle des plugins chaque plugin va essayer d'être idiomatique par rapport à la technologie auquel ils s'interfacent. Donc bien sûr quand on s'interface avec une base vectorielle et quand on s'interface avec une base relationnelle les plugins vont parler vectoriel, vont parler relationnel et après, ils vont mapper vers le format Ion. Bien sûr, il y a des moments où quand tu maps sur un format Ion, si c'est un vecteur chaque donnée Ion ce sera un tableau de bytes. Donc oui, là tu es dans la limite des choses mais après ça va être utiliser les différentes tâches, si tu fais du vectoriel certainement c'est qu'après tu veux faire du RAG par exemple ou tu veux faire des choses comme ça ou tu veux faire de la recherche vectorielle donc là tu vas utiliser toutes nos tâches qui permettent d'aller faire des workflows d'IA avec du RAG, d'aller faire de la recherche sur des bases vectoriennes.
Bruno:
Alors je sais que j'ai des questions qui sont peut-être très orientées data, mais parce que les orchestrateurs, moi je les vois en général plutôt sur des aspects data, c'est là où on va être utilisé, notamment aussi pour des questions de volume de données. Alors effectivement, tu es venu faire le compilé de l'épisode d'Andrien où on parlait de performance, et c'était évidemment un de tes sujets, mais donc la question s'applique aussi là pleinement. On parle effectivement de tera de data de tera octet de data qu'il faut pouvoir manipuler on n'a pas forcément envie d'attendre 4 jours de tout charger, de tout traiter de tout réuploader comment est-ce qu'on peut du coup, optimiser la manière dont ces flux de données toujours plus importants sont traités ?
Loic:
Alors dans Kestra il y a plein de manières de faire, quand t'es sur du tera octet de données de toute façon il faut que la donnée ne bouge pas il faut que tu aies du calcul distribué donc là moi ce que je te conseille, tu vas utiliser un plugin qui va s'interfacer avec du Spark, de l'Apachi Beam ou des choses comme ça, bon mais ça c'est quand t'as vraiment des énormes use cases et là effectivement la plus value de l'orchestrateur c'est d'aller déclencher des gros batchs, des gros jobs ou des choses comme ça mais elle est pas énorme si tu veux faire un vrai pipeline de données. Là tu vas plutôt utiliser des tâches qui vont, comme je te disais et comme j'expliquais aller charger de la donnée, le mettre dans un fichier et chaque tâche va travailler avec le système de fichier parce qu'il n'y a que comme ça que tu peux stocker de la donnée. Dans Kestra, c'est vrai que j'ai beaucoup parlé des systèmes de fichiers, mais on peut avoir des outputs dans chaque tâche qui sont stockés dans le contexte d'exécution. Donc bien sûr, si tu es sur de la giga de données, je te déconseille de le mettre dans le contexte d'exécution. En Kestra 1, qui est la version actuelle, ça faisait tout planter. Bien sûr, parce que tu chargeais un compte d'exécution d'un giga en mémoire. Bon, si tu es tout seul, ça va. Si vous êtes trois, bon, voilà. En Kestra 2 on a basculé tous nos outputs sur du stockage en base et on les récupère de manière, lésie seulement quand c'est nécessaire donc tu pourrais le faire mais c'est un peu contre performant il faut savoir que même si t'es sur du fichier, t'as quand même des tâches Kestra qui permettent de traiter de la donnée ligne par ligne qui sont assez performantes pas aussi performantes qu'un système dédié comme du Spark ou des choses comme ça mais qui sont quand même assez performantes entre autres on a intégré du scripting au sein de la JVM donc t'as pas besoin de démarrer un conteneur ou de faire un process sur la machine c'est du scripting dans la JVM. En javascript en Python et je sais jamais en Groovy donc c'est via le projet GraalVM et donc là vraiment on est hautement performant parce que GraalVM permet que ces langages soient grosso modo il va transformer ton script en bytecode Java qui va ensuite être compilé par le JIT. Donc c'est presque aussi performant que si tu le faisais en Java, mais ça reste du scripting dans la JVM.
Bruno:
Et sur le... Je reste encore sur mes sujets data, je suis désolé, mais il y a aussi quand même un... Il y a un intérêt quand même assez fort qui est posé à la data. Il y a une certaine sensibilité, on va dire, une certaine notion de sécurité adressée avec la data. On n'a pas envie qu'un mauvais job puisse se lancer et potentiellement altérer ou modifier la data. Comment est-ce que vous adressez justement ces sujets de validation, de rollback de s'assurer que ta donnée elle reste intègre de bout en bout est-ce que c'est uniquement à moi de m'assurer que mon script est bon ou est-ce que vous avez des moyens du coup de revenir en arrière ?
Loic:
Alors c'est à toi de t'assurer que ton script est bon effectivement, on n'a pas vraiment de moyens de retour en arrière parce que Kestra n'est pas maître de la donnée donc en fait le moteur de Kestra lui, tout ce qu'il voit c'est des tableaux de bytes qui passent et qui balancent et qui transfèrent de fichier à fichier les outputs tout ce qu'il voit c'est des maps c'est la seule chose qu'il connait, après on s'interface avec des systèmes de data quality on s'interface avec les systèmes de data lineage on permet aussi même de faire du lineage au sein de Kestra avec un système d'asset, management, donc on a des choses qui tourne autour de la qualité de la donnée. Pour l'aspect sécurité de la donnée, On a le fait que chaque workflow est étanche, c'est-à-dire que même dans ton script, tu ne peux pas sortir de ton répertoire, tu ne peux pas accéder à un fichier d'une autre exécution. Donc ça, il y a certains qui trouvent que c'est chiant parce qu'ils disent « dans telle exécution, j'aimerais bien accéder à un autre fichier ». Non, par défaut, on refuse. Tu ne peux pas accéder au disque dur il y a plein de choses qui permettent de limiter les risques d'erreur donc on évite que tu te tires trop souvent une balle dans le pied, et en enterprise on a des règles de sécurité plus poussées avec le airbag qui va permettre à tous les niveaux de limiter ce que peut faire un utilisateur.
Bruno:
Quand tu dis airbag c'est une techno en.
Loic:
Particulier role based access control c'est classique après on a on a une techno très particulière dans la version d'Enterprise on fait ce qu'on appelle Java Security donc c'est vraiment du workload security, c'est à dire que quand tu exécutes une tâche et que tu actives cette fonctionnalité, si tu accèdes au fichier si tu veux démarrer un process sur la machine si tu démarres un thread. Quelques petits points comme ça, On va vérifier si t'as le droit. On va dire non par défaut. On va dire non, tu ne peux pas faire du process. Tu ne peux pas accéder à un fichier en dehors du working directory de la tâche. Tu ne peux pas démarrer le process et ainsi de suite. Donc ça, c'est vraiment pour du hardening un peu élevé. On a quelques clients qui l'utilisent principalement, toujours les mêmes use cases, beaucoup dans la finance. Donc voilà, on a quand même des trucs de sécurité. Ça évite, tout d'abord, comme je t'ai dit, on a du scripting dans la JVM. En scripting dans la JVM c'est pas compliqué, avant en 1 tu pouvais faire un peu ce que tu veux parce qu'on avait du scripting dans la JVM qui utilisait Nashorn qui a un autre projet pour faire du JavaScript dans la JVM comme maintenant, en 2 ils vont être supprimés ils seront dépréciés depuis longtemps et avec GraalVM déjà on a un mode de sandboxing mais il est pas, à toute épreuve et donc là on a du Java Security donc pour la petite histoire, je ne sais pas si tu connais Java mais il y avait un security manager dans Java qui permettait de faire ça en fait exactement. Donc à chaque fois qu'il y avait un accès fichier tu pouvais vérifier, à chaque fois qu'il démarrait un thread tu pouvais dire non et ils l'ont supprimé. Et donc comme on essaie de suivre les versions de Java on l'a réécrit avec ce qu'on appelle du... De la modification de bytecode à chaud. Donc on va avoir un agent, Java, qui va aller réécrire le bytecode d'accès au fichier pour pouvoir aller mettre nos checks de validation et pareil sur les démarrages de threads et tout ça.
Bruno:
Oui c'est vrai que la sécurité doit être quand même un sujet un peu sensible, c'est-à-dire que là, d'autant que vous êtes un orchestrateur qui fait pas que de la data mais aussi, toute une gestion de flow divers et variée, c'est-à-dire que ça devient un peu, le nerf de la guerre pour une boîte si tout passe par là ça devient un point d'entrée intéressant à creuser.
Loic:
Tout à fait comme on commence à être un peu connu donc là aujourd'hui on doit avoir quasi 27 000 stars sur GitHub. On a de plus en plus aussi de chercheurs en sécurité qui se penchent sur le sujet, et donc c'est vraiment un sujet aujourd'hui nous aussi on travaille avec les différents chercheurs de sécurité pour aller améliorer la sécurité de la plateforme. Mais c'est toujours très compliqué parce que, oui, OK, il y a une faille de sécu, ça arrive à tout le monde. Tout le monde en a une faille d'injection SQL, une faille de passe traversable sur les fichiers ou d'autres failles un peu plus bizarres. Donc ça, comme tous les produits, on en a eu. Peut-être qu'on en aura encore. On a des outils. Mais on a aussi une instance cloud. donc on commence à on a une offre cloud alors pour l'instant c'est une offre en bêta il n'y a pas encore de self-service sur internet, on voudrait prochainement mais pour l'instant si tu veux avoir une instance cloud tu dois nous contacter et on va te démarrer une instance cloud mais dans l'instance cloud c'est encore plus problématique parce que, là c'est nous qui faisons tourner du workload sur notre infrastructure, et donc on a passé la certification au SOC 2. Donc on a mis une vraie démarche sécurité derrière. C'est du SOP2 type 2. C'est la plupart des plateformes cloud. Et donc, c'est vraiment des sujets qu'aujourd'hui, on fait très attention à ce qu'on fait. On a une démarche d'amélioration de la sécurité et une vraie démarche avec les process de sécurité standardisés et ainsi de suite.
Bruno:
Oui, parce que j'imagine qu'effectivement, les contextes de chaque client sont bien séparés les uns les autres pour éviter qu'il y ait tout mouvement latéral de l'un à l'autre, mais effectivement, on pourrait imaginer quelqu'un qui arrive à injecter dans, la bio de son compte utilisateur sur un site en particulier, une commande particulière qui, quand elle passe dans un workload, lui permet d'accéder à certaines choses, mais j'imagine que... Comment tu peux... T'as évoqué le scripting tout à l'heure que vous écoutez dans la JVM. Je comprends que tu peux réussir au niveau de ton bycode à limiter les accès fichiers ou ce genre de choses. Mais comment est-ce que vous exécutez le code qui n'est pas le vôtre cette notion de scripting parce que pour Groovy j'entends qu'il y a la sandbox mais sur le reste vous n'avez pas forcément la même.
Loic:
Sandbox en fait il faut bien comprendre que toutes les tâches Kestra c'est du code Java donc en fait quand on utilise une tâche Kestra on définit ses inputs et ses outputs et il n'y a pas de code, exécuté qui est un code externe. Le code exécuté externe, c'est dans le script. Donc il y a les deux types de script. Scripting de la JVM, donc là on a le mode sandboxing de GraalVM, plus la sécurité Java dont je parlais, qui est fait via Bycode Enhancement. Et avec ça, on garantit normalement. On a eu plusieurs pen tests qui ont été faits et, A priori, on ne nous a jamais rien remonté là-dessus. Et après, pour les tâches de script, en fait, nous, sur notre cloud, et c'est ce que font la plupart de nos clients, d'abord, le task runner process, on ne peut pas le démarrer. Ça, je te le rassure tout de suite. Et en fait, le task runner, il est hardcodé et c'est du cube. Ce qui veut dire que chaque tâche de script, c'est un pod. Le pod, il démarre, il récupère les données qu'il a besoin dans l'internal storage et à la fin, il est supprimé. Et donc c'est comme ça qu'on se garantit et c'est vrai qu'aujourd'hui avec Docker, que ce soit dans du cube ou autre de toute façon c'est toujours des conteneurs Docker même sur du cloud batch c'est des conteneurs Docker in fine avec Docker d'un côté et avec. Le couple GraalVM qui a un mode de sound mounting plus la sécurité Java via byte count enhancement on est assez serein sur l'exécution des workloads de type scripting Ok.
Bruno:
Je vois. Quand on parle d'orchestration en 2026, on parle aussi beaucoup d'orchestration d'agents IA. Est-ce qu'il y a quelque chose qu'on peut aussi plugger dans Sanquestra ?
Loic:
Oui, alors on a beaucoup investi dernièrement sur les agents IA. Donc on a un plugin IA, donc c'est plugin AI bien sûr. Et dedans, on a un ensemble de tâches qui vont être agnostiques du provider. Donc je trouve que c'est le plus intéressant alors on a un plugin par provider on a un plugin OpenAI, un plugin Enthropic on en a une dizaine ou une quinzaine avec les tâches spécifiques mais notre plugin AI ce qui est intéressant c'est que tu as une tâche que tu utilises et tu peux ensuite aller configurer ton provider, Ce qui veut dire, par exemple, qu'en dev, tu vas avoir ton workflow qui va utiliser, par exemple, du lama. Comme ça, tu fais tourner un petit modèle lama dans un coin, ça ne coûte rien, tu fais tous tes tests là-dessus. Et puis, en prod, tu modifies la config et puis tu fais pointer sur OpenAI. Dans l'extrême, on a ce qu'on appelle les plugins defaults. C'est une manière de définir des paramètres par défaut pour un type de plugin. Et donc comme ça ton plugin AI Agent tu vas dire sur ton cluster de dev tu le configures par défaut pour utiliser un modèle provider. LAMA et en prod sur OpenAI donc, la tâche AI Agent c'est vraiment la tâche principale pour tout ce qui est workflow d'agents complexes on a d'autres tâches plus simples de type check completion image generation on a aussi tout un, côté sur tout ce qui est RAG donc tu peux faire de l'ingestion de documents dans une base de données vector, faire de la recherche ou faire des chat completion avec du RAG donc ça c'est bien mais l'AI agent c'est celui qui est le plus poussé, il gère à peu près tous les trucs assez classiques c'est à dire qu'on a une gestion de mémoire ce qui fait que tu peux utiliser plusieurs AI agent dans un même workflow et ils vont partager la mémoire, ils peuvent accéder à des bases vectorielles pour faire du RAG ils peuvent utiliser des outils des tools y compris du MCP. Dans les tools, on a aussi des tools spécifiques Kestra. C'est là où ça devient intéressant. C'est-à-dire que ton AI agent, il peut aller utiliser comme tools un flow Kestra. Et automatiquement, on va aller charger le JSON Schema. Il faut comprendre que chez nous, tout est JSON Schema. Donc, c'est-à-dire que chaque tâche a son propre JSON Schema, chaque flow a son propre JSON Schema. Ce qui fait que tu peux, par un programme, comprendre comment aller appeler un flow ou une tâche. Et donc on a des tools de type KestraTask pour dans ton AI agent aller juste appeler une tâche ou KestraFlow pour aller démarrer un flow et peut-être attendre son résultat, récupérer ses outputs ou juste le démarrer et ça et continuer. Ça c'est super intéressant mais on a aussi un tool qui est un AI agent, ce qui fait que tu peux avoir une tâche AI agent qui utilise d'autres AI agents et donc avoir un workflow AI à l'intérieur du workflow global Kestra Quel est l'intérêt ? Nous, on est déterministes Ton workflow, il est défini dans ton YAML, Si tu as un agent AI qui a des sous-agents, c'est dynamique, c'est non déterministe. Et donc, tu peux avoir le meilleur des deux mondes. C'est-à-dire que tu fais ce que tu veux.
Bruno:
Mais tu es quand même obligé de définir ton output, qui, lui, a quand même une structure donnée. Donc, tu es obligé d'avoir une forme de déterminisme quelque part.
Loic:
Alors, les AI agents, aujourd'hui, l'output, ça va être...
Bruno:
Du texte.
Loic:
Du texte. Donc là, tu t'en fous. Ou du structure output. C'est-à-dire que tu peux activer le structure output pour les modèles qui le supportent et définir ton output. Donc on fait les deux. Mais oui, ça a toujours des limites. Mais ce qui est intéressant, c'est que quand tu exécutes un agent IA au sein de Kestra, même si c'est non déterministe, dynamique et ainsi de suite, tu vas quand même tirer parti des apports de la plateforme. C'est-à-dire que tu vas avoir tous les logs de tous tes agents, de toutes tes invocations de tools qui vont remonter dans ta plateforme. Tu vas avoir toutes tes métriques y compris toutes tes métriques de token, count et ton nombre d'invocations d'outils et pour chaque invocation d'outils tu vas tracer toute la requête et ainsi de suite donc d'une certaine manière tu vas pouvoir savoir ce qui a été fait dans ton workflow tu n'es pas tout seul c'est pas comme si tu fais ton requête dans Cloud et puis il appelle 5-6 agents et tu ne sais pas ce qu'il a fait puis à la fin il dit voilà la réponse c'est 42 ok ça t'a coûté 50 dollars, on est d'accord donc voilà on essaye d'aller amener les deux mondes, avec une philosophie qui est de dire tu peux diriger l'agent IA si tu veux ou tu peux le laisser faire parce qu'il y a quand même pas mal de gens qui disent en fait un agent IA par exemple si tu lui donnes un tools pour appeler des flots tu lui dis quoi appelle n'importe quel floquestra ça va marcher. Ou tu lui dis, appelle un flow qui dit Hello World, il va le trouver tout seul. Mais est-ce que c'est la meilleure manière d'aller faire une invocation d'outil ? Est-ce qu'il ne faudrait pas plutôt lui dire, tiens, ton outil, c'est le flow Hello World ? Et donc, on a toujours les deux. C'est-à-dire que tu peux faire le mode un peu YOLO qui est bien pour le vibe coding et sur les présentations YouTube. Ou tu peux faire un truc beaucoup plus cadré où tu vas dire, tiens, mon agent IA, je lui donne ces trois flows. Je définis la manière de l'appeler. De ce fait, je cadre l'agent IA dans ce qu'il peut faire. Et généralement, tu as des résultats qui sont plus pertinents, en tout cas, plus déterministes.
Bruno:
On a eu pas mal d'épisodes autour de ces éléments-là. Et ce qui en ressorte toujours, c'est que moins tu donnes de tools à ton IA, plus efficace elle sera. Parce que sinon, en fait, elle commence à faire n'importe quoi. Et c'est ce que tu disais. En fait, au bout d'un moment, il te dit la réponse est 42, mais tu en as eu pour 50 dollars de tokens.
Loic:
— Ouais, et puis aussi, plus tes tools sont spécifiques. C'est-à-dire que si t'as un tools pour faire des calculs ou un tools qui te permet de faire que des multiplications, si ce que tu veux faire, c'est une multiplication, ce sera plus pertinent avec un tool qui fait que des multiplications. On ne risque pas d'halluciner et de faire une addition.
Bruno:
Mes questions sont forcément un peu naïves, parce que moi, c'est ce que j'explique souvent sur ce podcast, je suis un incompétent notoire. Je n'ai pas le niveau de compétence de mes invités. Les orchestrateurs, j'ai eu l'occasion plus d'en déployer que d'en utiliser directement. J'ai l'impression que... Alors je ne sais pas si c'est quelque chose qui manque réellement. Mais je... Parce que, en fait, de ce que je me promène dans un orchestrateur, en fait, tu as la liste de toutes tes tâches. Tu as évoqué ces différents triggers. Donc ça, ça va être, en gros, tu t'exécutes tous les lundis à 7 heures. Soit dès qu'il y a tel type d'événement tu te déclenches mais est-ce que ce qui manque pas ou ce qui devrait arriver prochainement parce que si je prends là tout ce que tu nous as listé sur Kestra, le nombre de types de workflow, que tu peux avoir, tout ça en fait ça consomme de la ressource, que ce soit en CPU en mémoire ou en ce que tu veux, est-ce qu'il ne faudrait pas un système où je peux dire à mon orchestrateur en fait voilà en gros moi de quoi j'ai besoin sur la semaine, et charge à toi de lisser la charge pour que, entre guillemets, ça me coûte le moins cher possible, pour pas exploser mes coûts en CPU, mais qu'en même temps, j'obtienne quand même les résultats que j'espère avoir.
Loic:
Je ferai écouter cette partie à mon product manager, à des product managers chez nous. On n'a jamais eu d'utilisateur qui nous a fait ces demandes. C'est intéressant, mais ça reste non déterministe. Et en fait, la plupart des clients, ils disent, moi, c'est de ça qui doit se passer.
Bruno:
Oui, tu as besoin de ton dashboard tous les lundis matins.
Loic:
Tout à fait. Par contre, tu as soulevé un point qui est le fait que une entreprise a des ressources finies. Et puis même quand ils vont être dans notre cloud, nous, si on leur offre des ressources infinies, peut-être, parce qu'aujourd'hui, ce n'est pas des ressources infinies, on leur démarre un cluster. Mais peut-être que demain, on pourrait avoir un système de ressources infinies élastiques. Ils ne vont peut-être pas vouloir, s'ils provisionnent 100 dollars par mois, ils ne vont peut-être pas vouloir payer 100 000. Et donc on a un ensemble de choses autour de ces problématiques de capacité. Une chose assez classique, on a du concurrency limit. C'est-à-dire que dans ton flow, tu peux dire, je ne peux avoir que 10 instances en parallèle. Et après, soit ça queue, soit ça fail, soit ça cancel. C'est comme tu veux. Le thème de queuing, c'était très compliqué. Il y avait le nombre de bugs. C'est moi qui l'ai codé. Tous les bugs, je les ai faits. Parce qu'on peut aussi, Kestra, donc on a plein de plugins, je t'ai dit, mais aussi, on a un orchestrateur qui peut être déployé un peu partout. Donc on supporte de la base de données MySQL ou Postgres. H2 en mémoire, mais on sait que c'est pour les tests, mais c'est très pratique. Et il y a des gens qui nous utilisent vraiment sur du H2 pour du Homelab. Ils démarrent H2 avec un fichier et comme ça, ils peuvent arrêter Kestra et ils redémarrent et ça reprend du fichier. On ne pensait pas que c'était utilisé en prod, enfin c'est du Homelab. On supporte de l'Elasticsearch comme base de données. Et on a un modèle de queuing. Donc soit tu peux prendre du queuing interne en Postgres ou MySQL, soit tu peux mettre du Kafka. Et dans la version 2 qui va sortir du Resis ou de la MQP donc tu vois on a une certaine complexité aussi au niveau du déploiement et je sais plus où j'en étais on parlait justement de.
Bruno:
Fluidifier la performance.
Loic:
Du système de queuing donc comme on a un peu cette complexité aussi, nos utilisateurs ils ont la liberté d'aller en production passer sur des systèmes Kafka et la Six-Sarge, par exemple, qui supportent beaucoup plus la charge. Là-dessus, on a aussi un système de worker group. C'est-à-dire que si tu es une très grosse entreprise, donc ça, c'est de la fonctionnalité d'un enterprise, si tu es une très grosse entreprise, tu peux dire, moi, j'ai mes systèmes critiques, mes systèmes moins critiques, mes systèmes en Asie, mes systèmes aux États-Unis. Et je veux dire, mon workflow, je vais le configurer sur le worker group avec des workers qui sont déployés sur un data center ou à le worker group avec des workers avec des super CPU et ainsi de suite donc on va permettre via les worker group, d'aller spécifier des workers donc de la capacité de traitement pour tel ou tel workflow donc on a ça, en version 2.0, là, qui va sortir dans quelques mois, bientôt même, enfin, dans quelques mois, on va aussi avoir du quota. On va pouvoir aussi gérer du quota, tout simplement. Donc, c'est plutôt comme ça qu'on va traiter les problématiques de capacité.
Bruno:
Donc, c'est pas en apporter forcément de l'intelligence pour lisser le truc, mais c'est donner les moyens aux gens qui l'utilisent, en fait, de pouvoir eux-mêmes gérer au mieux leur performance.
Loic:
Alors, quand on fait du concurrency limit, en fait, on lisse. Parce qu'on définit la limite. Mais le problème de faire de la répartition intelligente, c'est que c'est non déterministe et c'est pas forcément ce qu'on va vouloir les gens d'un orchestrateur, le quota donc ça va bientôt arriver donc ça va être vraiment tu vas pouvoir dire moi j'ai dans tel namespace ou tel flow ou des choses comme ça ou partenant parce qu'on a aussi une notion de multitenant je vais pouvoir avoir 1000 exécutions par heure par exemple.
Bruno:
Pour terminer, parce que j'ai l'impression que vous avez quand même tâclé énormément de challenges sur la solution de Kestra. Du coup, ma dernière question, ce serait, est-ce que vous avez encore des challenges ? C'est quoi votre plus gros challenge aujourd'hui ?
Loic:
On a toujours plein de challenges. Aujourd'hui, on a des challenges assez différents. Alors, on a toujours, on n'a pas trop parlé de la performance, Donc, on a toujours aussi cette volonté de rester très, très performant. Par exemple, moi, je considère que la couche d'orchestration ne devrait pas ajouter plus qu'une centaine de millisecondes. Il faut savoir que pour un workflow de deux, trois tâches, il faut savoir que tout est par message chez nous. Donc tu as un message qui te dit je démarre une exécution, un message qui te dit j'ai commencé à traiter la première tâche la première tâche est arrivée sur le worker nouveau message, le worker le traite le worker envoie la formation nouveau message et ainsi de suite donc ça veut dire que chaque message traité par l'exécuteur qui est le composant chez nous responsable du. Traitement de l'exécution du workflow même, ça doit être traité en quelques millisecondes donc on a toujours ce challenge là parce que par rapport à d'autres orchestrateurs on va, On va essayer d'être présent un peu partout, tu vois, comme on est universel. Donc ça veut dire qu'il faut qu'on puisse être présent sur des workflows qui sont au débit, à l'atteinte faible. Il faut qu'on soit présent sur des workflows data, pour des petites équipes de data, mais il faut aussi qu'on soit présent sur des grosses équipes qui ont plutôt des problématiques de gouvernance. Donc on a besoin de traiter plein de fonctionnalités, plein de use cases en parallèle. Sans trop perdre d'un c'est toujours une histoire de compromis pour chaque fonctionnalité sur comment on la code pour pouvoir répondre au mieux à la fonctionnalité sans impacter d'autres fonctionnalités Ok.
Bruno:
Canon. Merci beaucoup Loïc pour toute cette discussion j'aurais deux dernières questions pour toi qui sont les questions rituelles du podcast. La première c'est est-ce qu'il y a un contenu que tu serais partagé avec l'ensemble des auditeuristes ?
Loic:
Comme je n'y avais pas du tout pensé mais que tu as parlé musique il y a un groupe que j'aime bien qui s'appelle Visa, avec un Z. Ils ont un album Made in Tchernobyl. Donc, c'est des Ukrainiens qui est vraiment canon. C'est métal, mais pas trop bourrin. Ça s'écoute vraiment bien avec des chants un petit peu... Avec le côté un peu... Un peu ukrainien. Des sonorités un peu différentes. Ils ont été produits par le chanteur de System of a Done, si tu connais. Donc, c'est vraiment sympa. Je vous conseille d'écouter.
Bruno:
Ok, canon. On mettra des liens en description pour que les gens puissent les retrouver sur différentes plateforme. Et dernière question qui est la plus importante de ce podcast, Loïc, est-ce que tu es plutôt espace ou tabulation ?
Loic:
Espace.
Bruno:
Merci beaucoup Loïc.
Loic:
De rien.
Bruno:
Et merci à tous d'avoir suivi cette discussion. Voilà le sujet des orchestrateurs. Je pense que c'est des sujets qu'on va voir de plus en plus, si ce n'est déjà le cas. Je pense qu'il y a quand même pas mal de structures aujourd'hui où ça devient une nécessité et qui ne l'ont peut-être pas encore, mais je pense que ça devient de plus en plus nécessaire. Et en plus, quand on a des solutions comme ça, et françaises, et qui sont capables d'orchestrer autant de choses, je pense que c'est d'autant plus intéressant de les mettre en avant. Moi, comme toujours, je vous remercie de partager ce podcast autour de vous. Je vous souhaite une autre... Alors, non, non, cet épisode devrait être diffusé quasiment avant l'été. Donc si c'est bien le cas, je vous souhaite aussi de très bonnes vacances de fin d'année. Je vous ai préparé une série d'épisodes spéciaux pour cet été. Donc j'espère que ça va vous plaire. Ça va être assez intéressant. On parlera d'intelligence, mais pas artificielle. Sinon, moi je vous remercie beaucoup. Je vous souhaite une très bonne fin de semaine. Je vous donne rendez-vous la semaine prochaine. Et d'ici là, codez bien.
