
IA et Digital Twin – Avec François Fouquet de DataThings
Durée: None
Date de sortie: 23/01/2026
Voir sur Youtube
Animé par : Horacio GONZALEZ, VP DevRel chez Clever CloudAvec :
François FOUQUET : Co-founder, Head of Technology and Research @ DataThings
Antoine BLONDEAU : Engineering Manager @ Clever Cloud
Yannick GUERN : Software developer @ Clever Cloud
Episode enregistré le 9 janvier 2026
00:00:16 - Présentation des invités00:03:00 - Spec-Kit : Spec Driven Development
https://github.com/github/spec-kit
00:11:10 - Les impacts de l’utilisation de l’IA dans le développement
https://thecuberesearch.com/vibe-coding-ai-code-review-and-the-new-trust-gap-in-ai-generated-code/?utm_source=chatgpt.com
AI writes code faster. Your job is still to prove it works. - https://addyosmani.com/blog/code-review-ai/
Anthropic just open sourced the code-simplifier agent we use on the Claude Code team - https://x.com/bcherny/status/2009450715081789767
00:22:10 - DataThings et le Digital Twin
https://greycat.io/
https://greycat.io/talks/intro/
https://kopr-twin.com/ (major case study, national grid twin Luxembourg)
00:54:05- Musique de fin
NTO apnea - https://www.youtube.com/watch?v=oxuFA_9jmIQ
Montage : Yann BRESSON @ SMARTMEDIAS
Bonjour et bienvenue dans ce nouvel épisode de Mesasa Caractère Informatique, première
épisode de The Milvansies, épisode numéro sansan cantean.
Nous sommes les 9 yambies de Milvansies, je suis Horace Bonzales et aujourd'hui je suis accompagné
de Yann Merveillotte, le qui est Yannique, Yannique Tiela et aujourd'hui... Bonjour Yannique.
Salut et notre ambitée de jour, François Fouquet, François Tiela derrière, c'est super canard en plastique.
Bonjour, ça fait... Bonjour à tous les 3, merci d'être là pour ce premier épisode de l'année et
vous avez commencé un petit tour de table. Yannique, c'est toi de démarrer aujourd'hui, qui tu es,
qu'est ce que tu fais ? Je suis développeur matéria ERD, matéria étant notre gamme de base de données
serverless et du coup je m'amuse avec fondation DB et tout le framework qu'on a pu construire
dessus pour venir créer des produits pour Clever. Nickel, Panda, qui tu es ? Je suis développeur sur
la partie compute chez nous, donc tout ce qui est virtualisation, déployer des workloads dynamiquement,
tout ça, tout ça. C'est chiant. Et tu es responsable de nous venir sortir produits, non ?
Oui, ça fait un petit moment qu'on travaille sur un Kubernetes manager, effectivement.
Voilà. Et bon, François, actuellement, je te présenterai, contes-nous, qui tu es, qu'est ce que tu fais ?
Bonjour, donc moi je suis François, je suis le CTO,
il est un des co-fondateurs de DataFinks. DataFinks c'est une... Alors startup,
maintenant on commence à être un peu d'Atsa vu qu'on a pas mal d'années d'existence,
mais on est une des spinoffs qui a été créée par l'université du Luxembourg,
par moi et trois autres chercheurs. Et nous on travaille au sourd de tout ce qui est digital
twin et des technologies qui vont avec, c'est-à-dire qu'on fait des jumeaux numériques à
destination, le plus souvent, des gestions et des gestionnaires d'infrastructures,
donc par exemple la grille électrique, ce sera le use case avec lequel on pourra parler aujourd'hui.
Et pour faire ça, on a développé des techs de langage, de compiler et de base de données,
qui sont un petit peu au mix entre les bases, on va dire relationnelles, les bases time series,
graph et vecteur. Et puis je serais ravi de parler aujourd'hui avec vous.
Je pense que ça, ça va être super intéressant, il y a un côté les jumeaux numériques et les use case,
c'est de l'autre côté de la tech dur, c'est un bon démarrage pour l'épisode. Merci.
Bon bah et comme d'habitude, on a presque une heure pour vous parler un peu des différents souliers
de l'actualité tech et des souliers de faune aussi. Donc on a préparé un Yoli backlog,
je pense qu'on n'aura pas de tout le temps de les parcourir en entier,
alors qui va démarrer, qui va se lancer avec un soulier ? Oh Yannick,
il y a tes voix sourire, à toi de démarrer avec un petit soulier ? Je commence par quoi ?
A toi de m'a dire ? A l'espect kit. Quand on est en train de développer avec de LIA,
il y a un petit problème, c'est que LIA peut commencer à partir en VRI si on ne lui explique
pas clairement ce qu'elle doit faire et comment elle doit le faire. C'est un travail qui est assez
long à faire, on doit en fait s'improviser et écrivant et lui écrire des pages et des pages
de choses pour lui dire bah ça tu n'as pas le droit de le faire, ça tu devrais le faire de cette
manière et ainsi de suite. En gros, comme le disais ma métaphore, c'est de quoi qu'on
quand même ça y expliquait ça ? Ou est-ce d'ailleurs que vous viendrez arriver, qu'il n'a
ni le contexte de la boîte ni rien d'autre, ni le qui est extrêmement brillant pour écrire des codes ?
Il y a un piège qui est qu'on doit se remettre et écrire des spécifications correctes carré et
qui est quelque chose qu'on n'a pas forcément fait de manière extrêmement rigoureuse tout le temps en
disant toute façon c'est moi qui vais m'en occuper donc allons dire, allons dire que je vois à peu
pas où je vais et du coup on a oublié de revenir un peu une formaliste de savoir préciser sa pensée
à l'écrit pour que l'outil marche bien en face.
Alors déjà, spéckit, à quoi ça sert ? Ça sert à implémenter ce qu'ils ont appelé le
specification driving development. C'est vraiment ce qu'a dit Panda, c'est qu'on doit réécrire des
specs pour partir vers l'implémentation alors que on est plus tenté désormais d'essayer d'écrire
les implementations en ayant juste un cahier des charges. Donc on est obligé de revenir en arrière
sur le fonctionnement mais comme je l'ai dit, on est obligé de faire de la rédaction sauf qu'on
n'a plus le goût de la rédaction et il y a un truc qui est trop trop bien pour rédiger du coup.
Du coup on va demander à l'IA de venir générer les specs par rapport à des directives
qu'on lui a données précédemment. Donc c'est la IA qui va écrire les specs pour que l'autre IA
l'utilise et nous on va donner les directives à la première IA pour écrire ce specs, c'est ça ?
Et à partir de là on a une commande specify qui vient se rajouter dans notre paf. On lui dit
que on va utiliser tel type d'IA donc du cloud, du Gemini, du Amazon2, du et ainsi de suite.
À partir de ce moment là, il va venir générer tout un tas de cichiers qui vont venir faire de
l'injection de commande à l'intérieur du système d'IA. Donc par exemple si vous utilisez un cloud
vous allez récupérer des commandes en stage specify. Et c'est point quelque chose, ça va être par exemple
comment est-ce que le projet doit être fait. Par exemple dire je veux qu'il soit entièrement
fait en TDD, je veux qu'il soit observability first. Donc ça veut dire que la seconde,
une commence à écrire du code, il y a déjà le tracing, il y a déjà les métriques qui vont être
intégrés directement dans les implementations. On a tendance à écrire tout le code et puis après
on doit se battre à les foutre les traces un peu partout pour qu'on soit capable d'outiller le programme.
Là on dit à EspecKit, moi je veux que l'IA le fasse tout le temps sans qu'on ait besoin de lui demander à chaque fois.
Et par rapport à mettre tout ça dans un cifichier à JensponMD, comment fait-ce
d'aller vietnese, c'est-à-dire il y a deux mois ?
En fait le truc c'est que vu qu'on utilise Cloudcode, moi j'utilise Cloudcode pour presque tout,
on demande à Cloudcode au travers de la commande specify de nous poser des questions sur ce qu'on a envie de faire.
Ok.
Et ce qui est super cool c'est que c'est incrementale, c'est que quand vous allez lui rajouter du contexte,
lui il va commencer à vous poser plus de questions sur le contexte d'application.
Par exemple, si moi je lui dis que je commence à utiliser du fondation DB comme backend distribué de stockage,
il va commencer à me poser des questions, on me dit est-ce que ça serait intéressant que je rajoute les bonnes pratiques de fondation DB
dans les specs de guide pour l'IA qui va venir faire l'implémentation ?
Et de proches en proches comme ça on vient créer tout le cadre en fait du programme.
Donc ça c'est une première étape.
Et donc ça par rapport à écrire moi-même, il y a des choses que peut-être j'ai oublié, c'est j'ai écrit moi-même,
le fait qu'il me pose les bonnes questions ça va m'aider peut-être à m'y définir les cadres.
Exactement.
Donc ça c'est la première étape, c'est que je lui donne les frontières qui ne doivent pas dépasser pour venir implémenter les choses.
Et après on peut lui donner des directives sur qu'est-ce que l'on a envie de faire.
Donc là c'est le fameux cahier des charges qu'on a aujourd'hui pour faire l'implémentation à la main.
On va venir lui définir le cahier des charges.
Si on veut on peut même lui donner du cucumber et puis du coup il a le BDD, le Biver Driven Development
et il se démerde avec ça aussi.
Il pourrait très bien venir sortir des informations directement depuis le cucumber.
Ok.
À partir du moment où il sait comment il doit aller et où il doit aller, il va commencer à tracer un plan.
Donc un plan généraliste.
Là je vois que tu essaies de te connecter à une base de données.
Du coup tu vas avoir besoin d'un driver de base de données.
Du coup je vais te créer toute la partie de gestion du modèle qui est associé à la base de données.
Ok.
C'est marrant, moi je vois mes profs à la fois du ML et des sous-projets il y a dix ans qui me disent tu voyais,
tu vois ça sert à quelque chose de faire des spécifications correctes et précises.
Je le savais.
Il y a encore un moment où il vous t'a dit oui pardon, vas-y.
Les finis, finis.
À partir du moment où il a le plan généraliste et que l'utilisateur il a dit oui tu as bien compris
ce que j'avais envie de raconter ou alors on peut continuer à broder pour lui rajouter encore plus d'informations.
Il va être de dire combien de personnes tu es à bosser sur le projet.
C'est important parce qu'à partir du moment où il a cette information là il va pouvoir dire
ah tiens si tu veux spiter le travail entre trois personnes il ne faut pas que les différentes parties,
les imprémentations se marchent sur les pieds.
Et à partir de là il va créer un breakdown du travail à réaliser et venir dire là j'estime
le temps de travail à temps, le temps de travail à temps, le temps de travail à temps et pouvoir le dispatcher
aux différentes personnes.
Donc chacun va pouvoir utiliser son propre clott pour aller venir implémenter les différentes choses
au fur et à mesure.
LLM à ce project manager quoi.
Oui exactement.
Alors c'est vraiment ce que tu as dit.
Là on parlait des specs qui est la première étape de quand on commence à travailler sur un projet
mais ça me fait penser à un autre sujet qui est plutôt à la fin, le problème de la code review
avec les LLM, tous ceux qui utilisent des LLM vont avoir un peu de quoi je parle.
L'idée c'est que l'utilisation des LLM qui sont pertinents dans la génération de codes
nous mette face à un problème assez structurant dans le métier qui est qu'on se retrouve avec énormément
de gens qui produisent beaucoup.
Alors on ne pourrait se dire ce n'est pas un problème, si finalement on est tous en déboîte on va gagner de l'argent.
Il y a un point qui faut qu'on vérifie que le code est correct.
Et ça rend la tâche difficile pour deux raisons.
Déjà il y a beaucoup de codes qui sont produits et le code en moyenne que j'ai pu relire ces derniers mois
produit par les LLM est souvent pas simple.
Il pourrait être plus simple pour ce qu'il fait.
Il marche, il fait de la majorité du travail mais ça fait que la review est compliquée.
La review c'est déjà un équilibre assez instable dans un monde où il n'y a pas d'hier.
Parce qu'en fait on fait poser l'exercice de review sur les gens qui sont les plus compétents et qui ont le plus de temps à former
parce que c'est les gardes barrières qui garantissent qu'à la fin on met du code en prod qui fonctionne bien.
Donc là on a augmenté cette assymétrie là avec les LLM et on se retrouve à avoir du mal à suivre le rythme de review
qui est imposé à beaucoup d'endroits chez Clareur pour ce truc là.
Donc il y a plusieurs pistes.
Déjà comme disait Yannick si dans les specs et même dans un premier étage de pré-review
un truc sur lequel on est en train de commencer à travailler
mais un nouveau lien qui fait du filtrage sur des choses simples
tous les patterns de code qu'on ne veut pas voir
par exemple on peut considérer que nous dans aucun programme, ce cas là où j'avais chez nous
on veut voir un straw explicit
que tous les choses qui se rôlaient doivent être catchées etc.
Un certain nombre de règles ça enlève déjà du temps
mais sur les reviews de fond déjà
trouver tous les nouveaux patterns émergents qu'on ne connaît pas et qu'on ne sait pas encore qu'on ne veut pas voir
mais qu'ils sont un problème, il faut un humain
et puis de manière générale essayer de garder le code le plus simple possible
ça fait aussi partie du deal
et voilà
Ils viennent de sortir eux de Open Source en plugin cloud
Oui, Anthropique à Open Source en plugin cloud
qui est utilisé en interne pour simplifier les codes
et donc avoir des codes reviews sur un code plus simple
donc il sort de premier étapes automatisés avant les codes reviews
c'est d'abord, tu prends ce que Cloud a généré et tu les simplifies
Je ne fais pas même retrouver avec un jour une commande qui s'appelle Slash Simplify
ça va dans les messages
Effectivement la production de code
et je le fais pas mal
parce que je fais que l'effet qu'il y a de profil qu'il y a avant ne couvient pas
c'est pas que non le code sont plus de code
mais il y a aussi d'autres métiers qu'il y a avant
et je produisais plus de code qui le produisent plus
et que ça ne le produisait pas
et que le type ne dit pas que le code est intéressant
le type ne dit pas que le code est de qualité
donc il y a une façon de comment il y a un code généré
avec les deux liens, avec des backgrounds très différents
dans le projet, il y a un peu de...
de façon de faire qu'il y a des...
Et ça me pose la question
François, vous, en Data Things
Quelle est votre attitude par rapport à la IA
et la IA pour les développeurs pour aider à coder
ou générer des codes ou pas de tout
ou...
Alors la question est relativement multiple
suivant les personnes dans la boîte
et puis suivant les tâches auxquelles on a affaire
Pour être franc, on avait une approche très conservatrice
sur l'usage de l'IA
en particulier dès qu'on parlait des couches-coeur
des couches-basse de données
parce que...
peut-être d'un point de vue un peu arrogant
c'était les parties les plus difficiles à maîtriser
les plus aussi non existantes
c'est-à-dire que ce n'est pas des patterns de codes
qu'on assemble
c'est souvent du code assez original
et donc assez difficile
honnêtement à rentrer dans des IA
et puis c'est des zones où la moindre erreur
peut coûter cher
pas forcément qu'on crache
mais on perd des performances très très difficiles après à détecter
donc là le ratio coût fait qu'on avait un usage un peu moins grand de ça
après par contre
et là c'est plus maintenant sur notre avocat actuel
au vu des avancées de l'IA
sur la maîtrise d'un grand centre de type
d'attributs
de sources de données
comme on fait beaucoup de projets sur lequel on a beaucoup de sources de données
nouvelles pour lesquelles les mises à jour sont très fréquentes
on est beaucoup plus friands maintenant de l'IA
pour nous aider à générer les schémas
des bases de données
faire les suivis de maintenance de SaaS
générer les importeurs
en particulier parce que comme nous on développe des techs
qui sont relativement exotiques
moins connus
s'il y a nous aide finalement à ce que les gens mettent le pied à l'étrier
on met beaucoup beaucoup plus d'efforts
donc en gros on en parlera tout à l'heure
mais dans Grecat maintenant qu'est notre tech
on commence maintenant à développer
beaucoup de tools et de skills
pour Claude
pour faire le parallèle un petit peu avec SpecKit
qui a été abordé juste précédemment
on a pas toutes les réponses encore pour être francs
ça bouge vite
on se demande à quel niveau on doit aider les gens
à avoir un skills qui leur permet de mettre le pied à l'étrier
mais ça fait complètement partie
des roadmaps prioritaires maintenant
là dessus
donc voilà on a en gros 2 réponses
un très conservateur sur les couches très basse
parce qu'on dit les reviews de code
on est ligne à ligne sur du code C
on veut pas se rater
par contre sur les couches de modélisation
importeurs de données UI etc
là la réponse est complètement différente
non c'est clair que sur les intégrations
ça réveille le chenar
les intégrations avec
des systèmes dont la code base
et open source ou au moins les interfaces
sont open source ça fait gagner un temps
en fait
je pense que l'utilisation de LLM
m'a apporté un truc
je me suis rendu compte qu'il y avait énormément de choses qu'on faisait
qu'on n'avait pas vraiment envie de faire
et qu'on faisait parce qu'il fallait que ça fonctionne
mais typiquement nous un grand usage qu'on a
c'est le code de s'arrivalisation
il y a un moment
où tu as ton code métier, tu l'as défini
dans ton langage, tu sais exactement ce que c'est
donc on te dit jusqu'à là
on a partiellement de la semi-auto-derivation
mais il y a quand même des fois des cas où faut tout réécrire
et c'est pénible
et dans ce genre de cas ça nous fait gagner un temps monstrueux
et c'est l'étage à laquelle la plus value
qu'on a pour l'entreprise est vraiment limitée
c'est un peu robotique
j'ai envie de dire
c'est à ça que je pensais quand je parlais des importeurs
parce que souvent en gros on nous donne des dumps de csv
au tuyau chez parquet
il y a un ensemble d'attributs là
qu'il faut mapper avec les concepts du modèle de la carte d'oblité
c'est plus qu'on a ce que je veux
alors il y a une partie où il faut réfléchir
évidemment etc
mais il y a aussi une partie très très rémarbative
quand on a des csv à 150 colonnes
on n'a pas l'impression
de mettre nos capacités
d'ingénierie
quand on fait du copier-coller
à répéter ça
donc là on regarde particulièrement
sur ces couches-là
et puis la même réponse pour tout ce qui est
objet de transfert pour des API
avoir du type h côté type script quand on fait du front
on a déjà pas mal d'outils
on va dire basés sur les schémas
mais tout ce qui est de là-dedans
c'était vraiment rébarbatif
c'est clair et net où je te suis là-dessus
on est ravis de gagner du temps là-dessus
parce que notamment la plus value on la passait plutôt
sur le modèle métier à faire en sorte que
les raisonnements
et les fonctions de simulation soient plus pertinentes
c'est qui est assez intéressant
c'est que
beaucoup on était
au début extrêmement retisane
et à fur et à mesure que l'utilise
on voit des choses
dans lesquelles ça fait vraiment gagner de temps
et d'autres qu'on préfère faire
tranquillement soi-même
et c'est très courrier comme la réflexion
avance et ça va extrêmement vite
parce que l'outil aussi est le volume
plus extrêmement vite
je pense que sur le prototype
on a gagné énormément de temps
moi je trouve qu'il y a
plein de fois où j'avais des idées
de choses qui pourraient nous améliorer un peu la vie
et j'avais pas forcément le temps
de les tester parce que beaucoup plus
de choses à faire d'un point de vue produit
et le fait de pouvoir sortir
à partir d'une idée un prototype
en 45 minutes
de quelque chose d'un peu conséquent
et de faire un démonstrateur avec
ça vous a la possibilité
ça te donne plus de levier
pour mettre en avant des idées qui sont intéressantes
je trouve
parce que justement je réfère au bureau
et je vois Yannick et je dis
regarde ça m'embêtais de devoir
faire plein de tests sous couverneutes
à la main je viens de me faire un outil
de benchmark qui assa assa assa assa
et je le dis
et effectivement
c'est un truc que tu n'aurais pas fait avant
si tu n'avais pas eu
cette possibilité de les boostrapper
à Pitman
il y a d'autres sujets par exemple
quand on fait un programme
on a besoin de faire le pipeline de C.I.
pour venir vérifier les choses
sauf que faire du développement
de C.I. en fait c'est perdre son temps
parce qu'à chaque fois il faut relancer la C.I.
vérifier qu'est ce qui s'est passé
remettre l'information dans Claude
pour lui dire bah là ça a pété là
du coup qu'est ce que j'ai fait
j'ai demandé à Claude crée moi un MCP
pour me connecter à GitLab et aller lire les logs
directement des jobs et comme ça
tu as directement ta boucle de feedback
ça fait plus de gagner un temps
infini quoi mais jamais je me serais
lancé à faire le développement
du MCP GitLab parce que j'aurais pas eu le temps
parce que j'avais autre chose à faire
à côté mais là le fait
que j'ai pu juste le mettre
dans un coin dans une autre console
et que je suis revenu 45 minutes après
et puis j'avais déjà le truc
tu marchais ? Très bien
des prototypes
des loutillas, des DF
des codes de la plomberie
de la tuyautérie des codes comme c'est
que François disait
un sport CSV on va l'emporter
dans la base il faut m'appeler
chez moi Claude tu peux faire ça pour moi
carrément
c'est cool
bon
donc assis il froid Claude tu peux me le riche
fais gaffe ça arrivera bientôt
c'est l'étape suivante
François tu nous parlais donc
de GraeCat
moi il y avait 300 vies
que tu nous racontes
mais avant je me réveillais que
tu nous donnes un peu le contexte parce que tout à l'heure
tu nous as dit voilà
nous on travaille sur des humains numériques
et donc
de coup on était obligés de créer
de ton de technologie
j'ai envie de avoir plus de détails
de coup on a dû créer
de technologie, tu nous racontes un peu
comment on passe
de Vésoanne à la Techno
avec plaisir
moi j'ai un bagage de chercheur
je fais une thèse à l'Inria en France
et puis après on est venu travailler au Luxembourg
autour de sujets
liés à tout ce qui était telemetrie
pour les réseaux
et donc un des grands sujets à ce moment-là
c'était la collecte des coureoteurs connectés
qui nous envoyait tout un tas
d'informations temps réelles sur les réseaux
et pour lequel
on va dire les acteurs
par un public se poser des questions
sur qu'est-ce qu'on peut faire
avec ces données-là pour rendre le réseau plus résilient
et puis préparer avec les transitions
énergétiques par exemple
les mêmes questions se posent sur les réseaux d'eau
les réseaux de transport etc
donc on avait tout un tas de use cases qui partaient
dans des sujets très similaires
et donc on a commencé
avec notre casquette de chercheur, à un peu explorer
en avance quel type de recette
quel type de software pour ré-répondre
la question qu'on nous posait
pour en illustrer une par exemple
quand on dit on va faire une opération maintenant dans une rue
qui va être par exemple la semaine prochaine
à 14h qui sera impacté combien de temps
et comment est-ce que je peux minimiser cet impact
ça c'est une question très concrète qu'on nous posait
et on s'est dit
bon ben c'est marrant ça
comme use case
pour répondre à cette question-là je vais aller chercher
les télémetries de l'année dernière
les consommations des gens
je vais entraîner quelques prédicteurs des consommations
pour dire la semaine prochaine je pourrais dire qui consomme quoi
qui va brancher sa Tesla
et allumer son panneau sonnerre en même temps
essayer de répondre à ces questions
et puis tout d'un coup de se dire
bon ben quelqu'un doit avoir aussi le cadastre avec les câbles
et puis qu'on sache où l'énergie va passer
et puis vient très vite la question
du le câble il est gros à quel point
et si tout le monde
démarre sa Tesla en même temps, ça chauffe ou ça chauffe pas
du coup est-ce que c'est de la time series
est-ce que c'est du SQL
est-ce que c'est les trois en même temps
alors on commence par se dire
bon ben je vais faire un peu de time series
on attrape des bases time series
on joue avec ça
pour rien cacher on pleure quand même sur la quantité
parce que là les time series on parle
plusieurs dizaines voire milliers voire centaines de milliers
on tombe vite
sur des problèmes que les time series
avaient plutôt été faits pour monitorer
quelques séries temporelles
avec une granularité fine mais pas
énormément de séries temporelles non plus
les bêtes relationnelles bien sûr
ensuite on assemble les deux
on se dit la latence entre les systèmes
nous fait très très mal
parce qu'on s'est virmé de quelle sous partie
d'informations on parle et puis quand
les modèles de simulation arrivent là dedans
ça devient un vrai cauchemar j'ai besoin d'autres machines
et quand au milieu de ça
j'ai les algos de machine learning
on me dit non mais les consommations
c'est pas un truc que tu apprends globalement
c'est quelque chose que tu apprends unitèrement
chacun des consommations très différentes
donc quand je veux dire je veux prédire
la consommation du quartier et demain
c'est pas la consommation d'un client
lambda que je pensais la consommation
du client x y z
pour chacun j'ai un prédict
donc
finalement quand on a commencé les assemblages
on s'est vite dit
ça va faire très très mal
ça va faire très mal d'un point de vue plomberie
parce que beaucoup de systèmes ingénieries
ça va faire aussi très mal
d'un point de vue évolutivité de ces systèmes
ils vont coûter très cher et chaque fois que quelqu'un
va nous faire une nouvelle demande
il va falloir modifier toutes les bases et synchroniser
finalement on ne pourra pas répondre à ces demandes là
et ce qu'on a vite compris c'est qu'à l'époque
les digital twins étaient en brioinaire
c'est à dire qu'on ne savait pas vraiment ce qu'on allait faire avec
et même aujourd'hui c'est comme il y a toutes les semaines
on nous demande des nouvelles fonctionnalités
donc en gros bougez vite c'était essentiel
c'est quoi un digital twin du coup
moi je connais pas du tout le concept
le terme digital twin c'est simplement
de dire qu'on a un jumeau numérique
qui est calé au plus proche
d'une infrastructure souvent physique
en tout cas réelle
et donc par exemple
un jumeau numérique d'une grille électrique
c'est un clone virtuel
dans lequel je vais y faire
on peut parler d'une base de données
parce que c'est pas loin on va dire un modèle
objet ou un modèle mémoire
qui existe sur un ordinateur
qui régulièrement est alimenté avec
toutes les télémétriques qu'on connaît de ce monde là
sur lequel je peux faire
des tests de laisser erreur
on dit du motif dans le jargon
pour dire je fais un espèce de fork
de ce monde réel pour tester quelque chose
de ça j'en sors un KPI
une métrique et de cette métrique
je vais prendre une décision avec
les jumeaux numériques opérationnels
c'est des jumeaux numériques sur lesquels
en temps réel on fait tout le temps un essai erreur
par exemple, je coupe la grille
combien de gens sont impactés
est-ce que je peux le faire à 14h, 15h, 16h
je connais le bon horaire
du coup j'envoie un ticket de maintenant
quelqu'un part avec la voiture à 14h
par exemple c'était le meilleur horaire
il va aller agir sur la grille
donc de temps en temps on a aussi des réseaux numériques
actifs, on peut directement
envoyer l'ordre depuis jumeaux numériques
donc là il n'a pas de temps à fermer la boucle
ok, donc en fait c'est
une extension des outils de simulation
qu'on pouvait utiliser
je pense que ça m'a dans mon cas en école d'ingénieur
en code H canal ou en traitement de signal
où tu faisais un laboratoire très simple
mais de quel va être ton média
de transfert de tes ondes radio
et t'appliques des fonctions pour simuler
des perturbations mais étendues à tout un réseau
et utilisables directement d'un point de vue industriel
c'est ça, alors le terme
jumeaux numériques il couvre pas mal de choses
là ce que je vous décris c'est notre
compréhension, notre usage à nous qui est plutôt
des jumeaux numériques opérationnels
chez les académiques, il y a aussi des gens qui font des jumeaux numériques
par exemple c'est le modèle 3D
ça peut être le modèle d'un bâtiment, le modèle d'un avion
pour avoir toutes les agrégations d'information
et qu'on puisse tester des choses
avant de tester sur le système réel
parce que ça coûte moins cher
pour la base c'était vraiment un réplica
un simulateur donc le terme
était pas trop mal choisi
nous chez The Tracking's on fait
que des jumeaux numériques tant réels
donc c'est à dire tous les cas sur lesquels on applique
on n'est pas très loin du système de monitoring
telemétrie
et donc c'est ça qui nous a amené à réfléchir
à ces questions de tech
et donc par exemple pour la grille électrique
pour donner quelques chiffres
donc on a commencé à étudier ça pour le cas de Luxembourg
le Luxembourg c'est
350 000 compteurs connectés
qui envoient toutes les quart d'heure
4 valeurs
chacun donc en gros on ramasse
très très vite des millions de data points
qu'on doit garder
puisque finalement
il faut toutes ces valeurs là pour savoir
qui consomme quoi à quel moment
tu veux près dire une consommation
il faut que t'aies la consommation
donc
c'est un bon
passif
un bon historique entre guillemets de consommation
et puis le plus compliqué
donc c'est ça qui a amené à développer une autre technologie
c'est qu'en gros la consommation toute seule
bon c'est bien mais finalement ça ne mette pas grand chose
que j'ai besoin de savoir
quel est le contexte autour de ça
c'est à dire quel périphère est chaud
est-ce que vous avez froid
est-ce qu'il faisait chaud est-ce que les gens étaient en vacances
pas en vacances est-ce que c'est sur la pause
de midi ou est-ce que c'est le soir
est-ce qu'ils sont dans un quartier résidentiel
est-ce qu'il y a beaucoup de câbles autour
à quel câble ils sont connectés
quel est le transformateur le plus proche
toutes ces questions là sont contexte environnement
et donc voilà en gros c'est pour ça qu'on parlait
d'une base pas mal structurée
quand même assez grosse
et donc pour l'histoire
finalement on a commencé à s'orienter vers des bases
au début relationnel
pour s'en éloigner assez vite on se disait que ça ne fitrait pas du tout
la plupart des gens dans notre domaine sont partis
vers des bases graphes
et puis donc de fil en aiguille on s'est dit
il nous faut une base graphe
donc on va la développer parce qu'on n'était pas
très satisfait avec celle qui était sur le marché
et en particulier pas satisfait
parce qu'on avait besoin de time series
donc on a une base graphe étendue
avec les capacités de time series
puis est venu l'idée que
de toute façon il nous fallait aussi les modèles
de machine learning, les fameux producteurs
donc on a étendu le graphe avec ça
et puis voilà ensuite
les résultats vectoriels sont arrivés en disant
la base, la fingerprint de quelqu'un c'est un vector
donc il me faut les informations vectorielles
en plus et les no vectors
et puis de fil en aiguille on s'est dit
ah là si on fait ça
avec des langages comme cipher
c'est une horreur parce que finalement
j'ai des extractions, des queries etc
et donc on a mis du temps mais on a fini par accepter
de se dire il nous faut un langage de programmation
pour que le programme ne quitte pas le graphe
pour que au lieu de passer
d'un mode où on extrait les données
on les traite tant bien que mal
on les remap dans la DB
ce mapping là il était infesable pour nous
donc on s'est dit non mais en fait moi j'ai envie de faire un if
dedans, c'est à dire dans la DB c'est vachement plus simple
si je peux faire un loop les livres dedans
donc à un coup au lieu de devoir faire un langage
de requêtes relationnelles
ou autre avec des jointures
bon bah j'ai juste des ifs, else etc
et pour des gens qui ont un bagage impératif
pour nous c'était beaucoup plus simple
c'est marrant de voir à quel point tous les gens
qui règle des vrais problèmes arrivent aux mêmes conclusions
sur le processig de la donnée
et je
il y a un mot
ça doit faire trop quatre fois dans ma vie
où je vois des gens qui bossent sur des systèmes
où il y a un peu de données et qu'on devrait use case
derrière en quenng
et qui finissent tous par dire non mais ça doit être
exécuté là où il y a la donnée
il n'y a aucun monde où c'est gérable sinon
ça sort c'est compliqué
c'est ça
et donc voilà on a fini
par développer un produit comme ça
qui a eu beaucoup d'itérations, d'un prototype
de recherche, qu'on a codé
on en parlait tout à l'heure dans des langages comme Java ou Scala
puis après avec des besoins de performance
on les a fait évoluer
et puis de fil on aiguille
presque une des films plus tard
on a un prototype qui est codé en C
sur lequel le moindre byte à louer
on discute cinq minutes avant de savoir si c'est vraiment nécessaire
parce que vraiment ça va plus cher
et donc
on a développé ça
on a fondé une compagnie autour de ça
qui s'appelle DataFing
qui met en œuvre cette technolace
sur tout un tas de quai-studies
et on va dire un des plus gros, plus pérennes quai-studies
on a développé donc le digital twin
pour la grille de Luxembourg
aujourd'hui on couvre presque 95%
de tout le pays
c'est à dire que le twin dont on parle
connaît tous les câbles, tous les fusibles
tous les points de la grille électrique
toutes les sections, les matériaux
est-ce que c'est de l'aluminium, du cuivre
où ils sont positionnés, qui a des panneaux solaires
tout ça fait un énorme graph
parlant en milliard
pour ce graph là
et donc il a reproductu depuis
entre 2 et 3 ans maintenant
et donc on construit tous les quai-studies
autour de ça
pour les accords, pour les nouvelles installations de panneaux solaires
les tests de charge pour la grille etc
donc c'est un quai-studie
qui nous a amenés à bosser beaucoup autour de la tech
c'était cool, ils avaient beaucoup de données
beaucoup de demandes de simulation
et donc c'est ça qui nous a fait bien de gouverner
pour le côté framework
et c'est comme ça que Greca t'est apparu
c'est comme ça que Greca t'est apparu
et pour aussi la fin de l'histoire
c'est resté un framework interne
pendant très longtemps
c'est à dire qu'on l'a caché
pour avoir
on a fait une start-up donc il fallait
quand même aussi avoir un avantage compétitif
pour ces produits là
et puis depuis une bonne année, une année et demi
maintenant on fait l'effort de se dire
ça y est on en fait un produit pour les autres
avec l'idée que les autres développeurs
le prennent en main
qui est une doc qui se forme
qui l'utilise que ce soit à la main
ou au travers de l'élème
pour qu'ils règle leurs problèmes et qu'on reprenne
une casquette d'éditeurs logiciels là-dessus
et si c'est pas discret
qu'est-ce qu'il vous a fait, Jean-Dier David
les montrer c'est qu'il y avait sous le capot
ah c'était le plan
dès le départ
c'est simplement qu'on voulait avoir le temps
d'avoir des implementations de référence
parce qu'en fait le problème de ce genre de produits
c'est que c'est un peu incontrecurrent
et donc si on dit
on a une idée et puis on a un bout de proto
et puis on est chercheur et donc voilà
venez jouer avec nous
avec nos potes académiques ça se passe bien
mais avec les industries il y a peu de chance
que les gens parient là-dessus donc il fallait qu'on ait
des déploiements très sérieux
et des cas de référence en disant voilà on a testé
sur la grille électrique, on a des cas bancaires
on a des cas dans l'industrie 4.0
on a des cas sur des choses
plus exotiques comme la gestion
d'arrosage d'arbres et de zones vertes
donc on a essayé de balayer tout un tas de questions
pour dire voilà si vous avez des choses
là-dessus on a au moins un point de référence
et maintenant venez jouer avec nous
et vous savez qu'on parle pas de rien
c'est pas juste une idée farfelue
et je pense que c'était important parce que
c'est dur de proposer une nouvelle tech
c'est dur de proposer en particulier des nouvelles choses
dans les bases de données et de langage de programmation
donc fallait qu'on ait ça pour avoir quelque chose de sérieux
donc c'est ça le virage
et qu'on pense que maintenant on a eu assez
de bagages, de projets
pour qu'on puisse être là aujourd'hui et à vous dire
venez jouer avec nous on sera contents
et pourquoi Chagri du coup ?
alors Chagri
bon on est chercheur
on avait toujours
tout un tas d'approches bizarres
pour les noms et les choses
je le jure
le premier nom de Grecat c'était
Many World Graph Database
il y a très longtemps côté
côté académique
et pourquoi ? parce que cette base en fait
elle fait des forques comme je l'ai dit
c'est à dire qu'elle a toujours X au coup d'avant
si elle monde réelle et puis il y a les mondes hypothétiques
et en fait la bonne solution
elle est souvent au milieu de ces mondes là
c'est jamais tout blanc ou tout noir comme on dit
c'est à dire que finalement
c'est pas un bon hypothesis
et puis la bonne
hypothèse elle est souvent au milieu
d'où le gris
c'est jamais blanc ou noir c'est gris
et c'était un explorateur
des cas d'usage
pour trouver la zone grise on va dire
le bon trader
excellent
merci et j'ai vu
qu'il y a
une version qui te permet
de l'installer toi-même
pour commencer à jouer avec
parfait
alors comme on est une petite structure
on ouvre progressivement tout ce qu'on fait
le but étant
de permettre aux gens d'évaluer ça
de garder aussi une casquette
produit de l'autre côté
c'est toujours un monde
pas facile
à naviguer
donc on ouvre progressivement tout ce qui
permet aux gens de jouer sur Greca
donc aujourd'hui c'est une version gratuite mais complètement exploitable
même en production
dans d'autres infrastructures
cette version est gratuite
parce que là tous les modules de base pour faire des twins
nous on se réserve bien évidemment
en certaines hybrés avancées
qu'on se garde sur des cas plus professionnels
et plus avancés
et puis pour le côté
source versus pas open source
on a déjà ouvert tous nos SDK
les formats de stockage etc
pour que les gens soient surtout pas vendeurlock
parce que ça c'était pour nous essentiel
et puis pour le coeur on ouvre progressivement
mais surtout avec l'idée qu'on veut que les gens collaborent avec nous
donc souvent on partage les sources
avec les gens qui signent par exemple un accord de partenariat
ou des amis chercheurs qui travaillent avec nous
donc c'est pas du source fermée
c'est pas du source complètement ouvert pour tout
parce que encore une fois
on est une petite structure
il faut que globalement on s'assurer la péremité
de ça donc on cherche cette ligne là
et on collabore
avec grand plaisir avec les gens qui veulent travailler avec nous là-dessus
et puis pour les autres
on est aussi ravis de leur offrir du support
et un produit pour qu'ils aient quelque chose qui tienne la route
en production
ça me semble un bon modèle
et voilà c'est pas...
si je comprends bien du coup votre modèle
c'est de proposer du digital twin
à des industriels
en premier lieu
et d'extraire tout ce que vous créez comme outillage
pour répondre à ces besoins
et développer entre autres Grecat
comme solution
basalette sur quoi, le financement
on utilise Grecat pour tous les digital twins
qu'on fait à DataFix
on a une activité de servicing
autour de ça où on dit au gens voilà on vous met le tiel étrier
vous nous donnez votre use case
que vous voulez résoudre
on fait le digital twin pour eux
jusqu'à présent comme je disais on le faisait tout seul
maintenant on préfère leur dire
on s'associe avec d'autres équipes
par exemple des gens qui ont une force de frappe
de développeurs bien plus importants que l'un autre
on les forme
on met souvent le tiel étrier parce que le nouvel tech
donc il faut commencer
et puis après on les laisse développer tout seul
soit en interne soit avec des partenaires de développement
et puis nous on reste en support
soit pour leur développer du code custom
de librairie si besoin
ou même faire du training ou du support
donc là reprends plus une casquette
d'éditeur logiciel plus classique
voilà en gros
la partie qu'on défend
comme notre produit c'est le CURS
le runtime d'exécution
par contre ce qui est évidemment non invasif et ouvert
c'est tout ce que les gens font avec le code
qu'ils écrivent dans Grecat et de Schéma
tout ça rêve bien évidemment leur propriété
donc ça se marie assez bien
avec des boîtes qui ont
des frémaux de développement
des capacités de développement
et qui veulent mettre en œuvre leurs développeurs
pour des acteurs publics par un public privé
donc voilà
c'est cool ça évolue
on voit que le marché sur comment on monte
des boîtes technologiques
est en train de se structurer
par rapport à avant
pour moi je sais pas il y a 5 ans
le cliché c'était j'ai une idée
je prends 4 mecs, je fais une série A
et c'est parti
je monte une boîte et je trouve
mon business model
et ils font série B
série C et en fonction de comment ils arrivent
avec les gens le financement reste comme ça
jusqu'au jour où c'est le drame
il n'y a plus d'argent, changement de licence
et puis
on l'a vu quand même quelques fois ce truc là
et
l'histoire que je vais me raconter
sur vous elle me fait un peu penser
à Mistral
où ils ont un produit très public
le char
pour les gens
mais en fait ils sont structurés en financement
et leur coeur de métier
en fait c'est bosser entre autres
avec ASML qui les a financés
et ils tailent leurs outils
dans ce cas-là
qui sont très industriels, qui sont à la fois
une preuve de validité de leur technologie
et à la fois un moyen de financement qui est pérun
c'est la ligne
difficile à tenir entre
avoir une boîte et pouvoir payer les gens
pour avoir quelque chose qui dure dans le temps
parce que ce genre de logiciel
il aide un maximum d'autres projets
donc il faut qu'on soit là, qu'on fasse vivre
que les développeurs soient payés
bien évidemment à faire ça
et puis d'un autre côté
il y avait le côté open source
sur lequel on veut que les gens puissent collaborer aussi
sur le long terme
mais monter une communauté open source
ce n'est pas si simple
donc oui la ligne n'est pas facile
on a pris ce pari là
je ne dis pas que ça a toujours été facile
mais en tout cas on essaie plutôt de partir
de cette vision là et à être prêts
d'ouvrir pour ce qui est tenu
En tout cas ça me semble aussi
quelque part, une façon de faire
presque parveçoin
dans les startups européennes
quand il parle des services A, C, B
il n'y a pas les mêmes financements
voilà
quelque part
en peu parveçoin mais les startups européennes
sont oubliés d'être
plus réalistes dans la prosse
et c'est plutôt le risque
parce que
tu peux pas dépendre
de l'un ou l'autre
qui ne se râpent pas
de n'importe quel concours
de l'autre côté de l'Atlantique
donc quel que passe
si une prosse
est raisonnable
et ça va plus parrain
de la maison
ou bien, c'est un relativisme
qui se débrouille
avec notre poste Cote Clever
et il apprend d'autres boîtes
qui sont dans ces façons de faire
OVH
pour être transparent aussi
il y avait un côté
même si on parlait de vitesse de développement
avec les LLM il y a des choses qu'on changeait
mais faire une DB c'est un processus
qui se distribue pas très bien
sur des grosses équipes de devs ça prend du temps
et on a vu des projets comme Postgre
où quand même on commençait il y a pas mal de temps
mais pour mes comites c'était un bon paquet de temps
et donc en fait
le côté explosif d'une start-up à l'américaine
avec des levées de fonds énormes
et de la visibilité directe
c'était risqué pour nous quand on veut commencer
quelque chose de scratch comme ça
parce que globalement si on active ça trop tôt
on se brûle en plein vol
c'est à dire qu'on a des produits pas prêts
et c'était beaucoup trop dangereux
on savait qu'il nous fallait du temps
maintenant on serait quand même content de gagner en visibilité
bien sûr et donc on est un peu jaloux
bien sûr quand on voit
le retour en la etienne on va pas
mais voilà on ne pouvait pas activer ça
à tout de suite
je pense que ce modèle-là
il est pertinent dans le fait que
il y a une forme de temps long dans l'ingénierie
qui est pertinente sur les systèmes complexes
qui est qu'en fait
à force de travailler sur le problème
on acquiert une maturité
un niveau de connaissance
sur les sujets sur lesquels on travaille
et que ça passe souvent par des récretures
ça passe sur toutes les danses interpièges
itérées
et ça
même si tu mets 100 millions sur la table
et 300 mecs ça ne résume pas
nécessairement la connaissance que tu as
de ton milieu et
tu as un métu l'état opérationnel
et puis comme on disait
c'est des acteurs qui ont
des problèmes aussi beaucoup de type de données
donc de les traiter en parallèle
par exemple si on avait eu plusieurs réseaux électriques
en parallèle qui nous auraient posé plein de questions
sur des axes différents
on n'aurait jamais pu avancer sur ramets
d'une seule direction et puis finalement
avec quelque chose qui se mature
donc là d'avoir un golden customer
qui nous aide un petit peu à dire
on avance là dessus, on va le plus loin possible
et à chaque problème
on améliore la solution et on va au-delà
c'était beaucoup plus facile
d'un point de vue ingénierie
surtout quand il fallait faire face aux réécritures
parce que pour rien cacher
la première version n'est pas sortie
on va dire net du premier coup
donc bien sûr
il faut y térer, bien sûr on a des retours
et donc oui c'est un process très
très très iteratif
normal
ce type de
ce type de technologie
c'est difficile de ne pas les faire
de façon iterative
à plus d'un mesuron de tatouan
on connaît mieux donc on récris
et
pour être au front on s'est toujours dit bon
on attrape une brique logicielle qui est pas très loin
de ce qu'on a besoin
on va essayer de la sembler de faire
un peu comme ce qu'on fait avec les LLM aujourd'hui
on fait un prototype rapide et puis on fait quelque chose
qui va de bout en bout pour montrer à peu près à quoi ça pourrait ressembler
mais quand on parle de Graf
de 200 milliards de data points
il n'y a plus place à ça
et donc progressivement il a fallu reprendre
chaque brique et dire bon en fait c'est quoi
donc on a besoin là dedans on reprend ça
on parlait des vecteurs index
bien évidemment si j'ai un vecteur index
qui est indépendant du gras
ça va me coûter trop cher, les temps d'insertion de ça
la gestion mémoire de ça
donc on a bien fini par devoir
pas les recoder puisque ce serait arrogant
au sens de la plupart des algorithmes existent
mais en tout cas de changer la logique
pour lequel il s'intègre dans le
le software lui-même
par contre la bonne nouvelle c'est qu'à la fin
Grecat est quand même super simple
donc c'est là où je parle de gros questions
tu dis et de cas avec plein de données
mais à la fin si vous téléchargez Grecat
c'est un petit exécutable de 3M
il dépend de JLPC et Bastin
donc on est quand même
sur quelque chose pour des gens qui ont mis en place
des grosses tacks technologiques avec
10 conteneurs et
des zoos qui peurent au milieu qui essaient de jouer l'arbitre
quand c'est pas si facile
on va pas des touts de quoi tu parles
mais pas des touts
on sait que
pour on accumule des choses plus
c'est pas que c'est mauvais mais c'est pas si cool
donc à la fin
pour No use case à nous
on a fait une brique
assez monologique
ce qui fait un peu hurler mes anciens collègues
parce que je viens des idées
tout ce qui était micro services etc
et de découper la patate en autant de slices que possible
là c'est l'inverse
Grecat c'est un monolithe
un sol exécutable
plusieurs stores de stockage
et il fait tout en général
le plus sobrement possible
et pour lui d'aimer à s'en dider
je vois qu'il y en a qui ont
qu'à souffrir
il n'y a aucune idée de ce que je disais tout à l'heure
je ne
il n'y a pas de spacé à mettre
il souffre encore
il ne se compatit encore
et qu'on a essayé de se simplifier
la vie on n'a pas toujours réussi
en tout cas on a essayé
mais pour vous donner un ordite d'idée
la grille de Luxembourg tourne sur une machine
on a une seule machine
elle est quand même grosse
entre 64 et 128 heures
et un bon
pas grave
elle machine
c'est pas un giga cluster de calcul
et donc on était assez content
parce que finalement c'est un gros case study
sur lequel on se dirait
sans scalabilité horizontale on n'y arriverait pas
la scalabilité horizontale
nous apporte plein d'autres choses
pour la haute avidabilité etc
mais en tout cas c'était pas nécessaire
strict au sensu pour faire passer le calcul
c'est ça qu'on voulait aussi démontrer
en développant le Gricap
je crois qu'il nous l'a bien vu
je pense qu'il va y avoir pas mal de monde
qui va te les aller tester
pour commencer à jouer avec
le site est magnifique en plus
allez le voir
et la mascotte est géniale
les petits chats et les wireframes
il est trop mignon
pour ceux qui sont curieux
je pense le mieux pour avoir
petite idée
le site il y a quelques liens
il y a la documentation de manière un peu classique
mais à côté du lien
téléchargement de la page install sur grecati.io
j'ai mis un lien vers un tout petit hall que de Dyslide
où on essaie de donner un peu le pourquoi
ça peut donner une idée
ça se fait vite parce que comme il n'y a que Dyslide
après bien sûr on a des formations
plus sur le côté modélisation
mais ça aide à savoir
pourquoi on en est arrivé là
et pourquoi on a fait un gros hybride
entre une base graph
une VM Java
et puis le serveur reste qui voit au-dessus
parce que voilà c'est pas toujours
une évidence
mais ça peut
ça peut aider à mettre un peu le pied à l'étrier
sur le pourquoi du comment
En tout cas
moi le système qui est simple
avec un couple d'apprentissage
réduit pour des use case
qui peuvent être aussi complexes
ça ne m'est pas
et ça est simplement
super intéressant parce que
quand tu fais de la technologie
pour des use case aussi compliquées
réussir à faire une technologie
qui les aiment peut s'approprier
ça n'a trop souffert
c'est pas évoluable de tout
C'est clair que oui
mais c'est vous que c'est assez impressionnant
que...
quand tu commence à creuser ces sujets là
tu sais que
tu vas rapidement tomber
dans je vais faire une transformée de fourrées inverses
et puis derrière je vais faire de la régression linéaire
donc il faut que ces outils là soient présents
mais pour autant il faut que
quelqu'un qui veut
je sais pas faire une moyenne de température
sur la journée de hier
ça marche de manière efficace aussi
ça devait faire tout un programme
de notation polonaises inversées
si tu vois ce que je veux dire
je le vois pas du tout
oui c'est ça, après
c'est là où on utilisait
côté académique on avait souvent plein de gens
qui développaient en plein de langages
et alors encore une fois
on n'a pas toutes les réponses mais souvent la personne
qui fait la fameuse transformée de fourriers un peu exotique
elle est avec
un langage avec notation polonaises inversées
qui est elle aussi tout à fait
elle est faite
pour son concept et sa façon de raisonner
et pourtant nous on devra l'intégrer
dans un système qui cause
avec des data points, avec plein de classes, avec plein de stockages
et nous on cause plutôt avec des objets
des fonctions, des conteneurs
et donc il faut
un peu faire la passerelle entre ces mondes là
et donc
bon voilà on a commencé grecate
en se disant nous on focus sur les données
parce que nous notre métier c'est de faire des graphes
donc des gros gros graphes donc on a fait ça pour nous
et puis après progressivement on a fait plein de binding
pour les gens, bon
la transformée de fourriers je suis pas forcément le plus grand expert
ou là dans notre cas
la fonction de power flow sur les gris électriques
je suis pas toujours le plus grand expert
c'est pas mon bagage donc écrit là
dans ce que tu veux
et puis moi je vais découper un petit morceau
pour t'appeler ça pas trop souvent pour que globalement
à la fin du sens prototype il tourne raisonnablement vite
et que
voilà on met ta dispose et résultat là
non pas pour un rapport annuel
mais maintenant pour tout le monde et c'était ça qu'on voulait avoir
c'est à dire que ce genre de calcul
faut se dire sur la gris électrique c'était fait annuellement
par exemple parce que pas le temps
parce que le gars qui fait les transformées de fourriers
il
il ne l'a pas non plus que ça à faire
mais c'est pas si facile que ça
de mettre ça derrière un API
et donc on se dit si on fait ces calculs régulièrement
et bah on passe d'un moment sur lequel on est un peu aveugle
sur les résultats
à quelque chose ou bah on chiffre un peu quoi
donc ouais
en tout cas je suis impressionné par la proche
c'est
carrément
super intéressant
on va voir qu'est ce que ça donne quand on l'installe
mais carrément super intéressant la proche
les sites bien clairs
ça explique bien et
ça c'est sûr je vais aller l'installer et tester
ah bah tester
et puis bah ouais
n'hésitez pas à nous faire des retours
en particulier on espère que
des développeurs qu'on embagage de langage impératif
quel qu'il soit
on parle de Java, de Scala, de Rust
et de Python
devraient normalement trouver leur billet assez vite
et donc on a fait certes un nouveau langage
mais finalement il n'a rien de nouveau
au sens conceptuel c'est juste un langage impératif
qui quitte pas la DB
mais ça reste un langage impératif qui est un peu
très classique et si vous me dites
il est classique je serais content parce que
ça veut dire qu'on vous a pas perdu
sur le chemin et qu'au final c'est juste le runtime
qui est censé faire un peu
sa magie entre gestion stockage et mémoire
je vais faire un stream twitch
et tout cas la VOD pour
analyser toutes mes réactions de
ah non ah je comprends pas
ah bah bien sûr c'est comme ça
et tout cas
les exemples sur les sites ça c'est
littréable et langage
je dirais pas c'est classique
mais oui c'est pas
c'est pas un langage
et à l'air compliqué à lire
c'est un bout de goût
la seule notion
par rapport à un langage objet c'est qu'on a une notion
de nœud parce qu'on est dans le graph
finalement un graph c'est des nœuds qui sont reliés les uns aux autres
donc on a des notions de nœud qui sont des conteneurs
dans les conteneurs on peut mettre des objets
et puis on a des conteneurs qui sont des séries
temporelles géospatiales ou vectoriaires
ça c'est l'idée principale
et en gros comment on fait les arcs
entre les nœuds du graph c'est des attributs
des objets contenus qui permettent de pointer vers
les autres, ça ressemble à des pointeurs
pour les affiches sur l'adode
si plus plus ou de reste
ça ressemble à un pointeur sur lequel on peut naviguer
sur un autre nœud et puis de proches en proches voilà on fait le graph
donc en gros à la fin
une fonction, une requête c'est censé
on prend un point de départ puis on déroule
on jump on jump on jump on fait des boucles forts
on fait des filtres si on a besoin de résultats intermédiaires
on fait un gros tableau, une grosse map
et puis on fait tout comme ça en fait
on est en train de le faire
on fait tout comme ça
on va voir
ça fait presque 5 à 5 minutes qu'on parle
donc je propose qu'on coupe cet épisode ici
et pour ça
il me faut une musique de fan
donc François
qu'est-ce que tu écoutes en ce moment
que tu voudrais faire partagé
à nos auditeurs
qu'est-ce que tu voudrais les mettre dans les oreilles
pour finir l'épisode
euh
qu'est-ce que j'écoute
qu'est-ce que j'écoute
j'écoute un groupe qui s'appelle NTO
euh
par exemple
l'album Apnea de NTO
ça fait des choses
que je me mets en boucle
j'écoute pas mal d'électro, ça tourne souvent en boucle quand je côte tard
donc Apnea d'électro
nickel
boba
donc on va vouloir c'est avec
Apnea de NTO
merci François
de nous savoir
de me demander si tu as la légère de Greigat
merci Pandan
merci à NIC
merci à tous de nous savoir
et à très bientôt
bonne journée
bonne journée, merci
à sens
Les infos glanées
CleverCloud
Tags
Europe, Open Source et souveraineté numérique – Avec François Fouquet de DataThings