Bruno:
Une application industrielle, c'est un peu comme une cathédrale. A force de rajouter des chapelles et des gargouilles, personne ne sait vraiment où commence la voûte principale. Après 30 ans à coder pour l'industrie lourde, on se retrouve tous au même point. La dette technique s'accumule, la vélocité fond comme neige au soleil et on passe plus de temps à réécrire du plumbing qu'à bosser sur le cœur métier. Mais alors, pourquoi est-ce qu'on écrit toujours autant de codes d'infrastructures ? Est-ce qu'on peut vraiment réhabiliter le CRUD et arrêter d'avoir à travailler sur ses effets de bord dans tous les sens ? Et surtout, si on laisse des robots générer du code d'infra, est-ce qu'il ne nous restera que de la cosmétique à faire ou on aura enfin plus de temps libre pour l'apéro ? Pour répondre à ces questions de fondation numérique, je ne reçois pas Violet-le-Duc, mais il s'y connaît en structure logicielle. Jean-Christophe, bonjour.
Jean-Christophe:
Bonjour Bruno.
Bruno:
Alors Jean-Christophe, est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?
Jean-Christophe:
Je pense que peu de personnes me connaissent. Je suis Jean-Christophe Leduc. Je suis créateur de l'entreprise Lumiscaf, qui a été créée en 2001 avec mes associés, quatre associés, qui est une entreprise dans le domaine de la 3D pour l'industrie, 3D et XR pour l'industrie. Et puis là, aujourd'hui, je suis là pour parler de Digital Substrate, qui est une spin-off en quelque sorte de Lumiscaf. Donc le MISCAF en deux mots, c'est de la 3D pour l'industrie, notre principal client aujourd'hui c'est Renault et on fait les configurateurs, les images pour les configurateurs 3D de Renault que ça soit sur site internet ou en concession et on fait les outils pour remonter toutes les images en processus de l'ingénierie jusqu'au marketing. Donc c'est la catégorie qu'on appelle CPQ dans le domaine de la 3D.
Bruno:
Donc c'est pas de la 3D au sens du rendering, enfin de la modélisation d'objets ?
Jean-Christophe:
Non, on exploite la modélisation déjà présente dans des outils comme Katia typiquement, et qui sont destinés à fabriquer les produits et pas à les représenter visuellement. On extrait la matière première de ces fichiers CAO et on les met en forme pour pouvoir faire de la visu 3D photoréaliste.
Bruno:
En sachant que les outils type Katia est un peu lourd, qui font la 3D de manière assez fat, on pourrait dire. Donc j'imagine que pour en faire du rendering, il y a quand même tout un travail, de gestion de la 3D qui est assez complexe.
Jean-Christophe:
Oui, tout à fait. Et puis, on est aussi dans le domaine du fameux digital twin. C'est-à-dire que l'idée, c'est d'être capable de représenter le modèle final le plus réalistiquement possible, ou d'être connecté finalement entre le digital et le réel du mieux possible. Donc, avoir pour un industriel dans l'automobile un digital twin visuel, de l'aspect visuel du véhicule fini, configurable, animable, c'est un petit challenge. C'est pas si simple que ça.
Bruno:
Oui, j'imagine. Qu'est-ce qui a généré dans toutes ces activités que vous avez aujourd'hui chez Numismat ce spin-off vers Digital Subtrace ? C'est avec quoi les challenges que vous avez rencontrés que vous essayez de résoudre avec ?
Jean-Christophe:
Alors, très bonne question. En fait, on a commencé en 2001. On a développé un premier logiciel qui s'appelle Patchwork 3D. Et puis, on a continué à développer toutes sortes d'outils autour, satellites, qui viennent apporter différents valeurs ajoutées autour de la fameuse maquette numérique d'aspects, qui est le modèle 3D.
Bruno:
Un peu sur une philosophie micro-service ou vraiment des...
Jean-Christophe:
Non, c'est vraiment des logiciels desktop, clients lourds, et on a plusieurs formats de fichiers avec une sorte d'écosystème logiciel et d'outils satellites, finalement, qui tournent autour d'un format central. Et donc, ça fait du monde. C'est multi-techno, on touche à tout, au web, aux clients lourds, vraiment, on va dans tous les domaines. C'est assez intéressant, d'ailleurs. Par contre, ça amène une complexité en termes d'écosystème digital pour un éditeur, puisque on fait de l'édition qui est assez phénoménale en fait et surtout ce qu'on a constaté c'est qu'au bout des années passant, En fait, on a accumulé des lignes de code. Ce que j'appelle la surface logicielle s'est étendue. Et donc, la maintenance sur la surface logicielle, bien sûr, elle est proportionnelle. Donc, ça s'étend. Et je me suis rendu compte qu'on avait de plus en plus de mal à créer du fonctionnel. C'est-à-dire que nos clients nous disent, on voudrait telle fonction, on voudrait améliorer ça. Est-ce que vous pouvez faire ça ? Oui, bien sûr, on peut. Et dans notre tête, oui, ça va être rapide, ce n'est pas si dur que ça. Et la réalité montre que finalement quand on y va c'est beaucoup plus dur que ce qu'on pensait parce que quand on va toucher à du code au niveau fonctionnel de le nouveau métier on va avoir des impacts importants sur tout l'écosystème et on va tirer quelque chose d'énorme et au bout d'un moment nous on a appelé ça la viscosité c'est à dire qu'on a dit on a l'impression d'avancer dans une sorte de mélasse en fait et d'avoir une énorme déperdition d'énergie ce qui est assez frustrant tant pour les clients que pour nous donc ça c'était vraiment une sorte de souffrance et. Tout est parti de là en se disant mais est-ce qu'il n'y a pas un moyen d'éviter ça, est-ce qu'on peut pas, simplifier ça alors là nos gros outils sont écrits en C++ les clients lourds, c'est du C++ et 2 millions de lignes de code à peu près on a aussi d'autres langages on a peu près de tout et, l'idée c'est comment on peut réduire cette viscosité, comment on peut retrouver de la célérité dans nos développements. Voilà, c'était le point de démarrage, et ça, ça remonte à plus de dix ans, où on a commencé à réfléchir. Et puis, il y a cinq ans, ça a commencé à prendre forme, et il y a eu un déclic, en fait. Et on s'est dit, mais là, il y a quelque chose à faire, parce que finalement, on passe énormément de temps. Dans ce qu'on appelle aujourd'hui l'infrastructure logicielle. C'est-à-dire que si on prend une pyramide et qu'on dit au sommet, on a tout ce qui est métier, Ce petit cône en haut repose sur une base qui est l'infrastructure logicielle qui permet d'exprimer ce métier. Et ce que l'on constate, alors chez nous, dans un premier temps, c'est que 80%, 70 à 80% du code est dans l'infrastructure logicielle, qui n'a absolument aucun rapport direct avec le métier. Alors, bien sûr, le métier s'appuie dessus, mais ça n'exprime pas le métier. Et si on y réfléchit un peu, où est la valeur ? La valeur elle est dans le métier, 90% de la valeur de ce qu'on fait c'est le métier Alors il faut l'infrastructure évidemment, le logiciel il la faut, c'est nécessaire, Et donc là on commence à réfléchir, on se dit mais du coup cette viscosité elle apparaît principalement dans l'infrastructure logicielle, Et ce qui est choquant, c'est de se dire que les fonctions qui sont remplies par cette infrastructure que nous avons redéveloppée, alors c'est super sympa de redévelopper une infrastructure, on se fait sa stack, on se fait ses outils, il y a de l'intégration, il y a du développement pur, on a fait des tas de choses. Mais c'est sympa ok, mais on se rend compte que finalement quand on va voir un autre éditeur logiciel il a fait exactement la même chose quand on va voir un troisième c'est pareil un quatrième c'est pareil et on se rend compte que il y a, dans les équipes, comme dans toutes ces équipes comme dans notre équipe il y a des tech leaders, des gourous des gens qui sont brillants qui ont eu des idées, qui ont mis en place leur infrastructure logicielle pour simplifier l'expression du métier, mais Mais au final, on a tous réinventé une infrastructure. Et quand on regarde bien au niveau fonctionnel, purement technique de l'infrastructure, on a tous réinventé un peu la même chose. Alors, ce n'est pas exactement la même chose. C'est coloré, c'est adapté au terrain, au métier, justement. Ce n'est pas exactement la même chose.
Bruno:
Mais dans le besoin final, dans ce à quoi ça répond.
Jean-Christophe:
On tape toujours sur l'infrastructure digitale, c'est-à-dire c'est énorme, les besoins sont énormes à ce niveau-là. Mais effectivement, on réinvente tous un petit peu la même chose. Alors on utilise des frameworks, des bibliothèques, des outils, toutes sortes de choses qui ont bien sûr simplifié ce travail. On n'est pas en train de coder en assembleur, heureusement. Mais même quand on fait ça, c'est facile. Quand on écoute les développeurs, la première chose dont ils parlent, c'est qu'elles s'utilisent comme stack ? La stack, ce n'est pas du métier. Donc, ah oui, tu utilises tel stack, mais ça plutôt que ça. Et voilà. Donc, du coup, il y a cette espèce de gros mécano quand même, qui est là quand même pour faciliter le travail. Mais malgré tout, il y a un énorme investissement, quel que soit la stack, quels que soient les outils, je dirais. Je parle bien des développeurs, pas des outils no code ou low code. Mais quand on est dans le développement, il y a un énorme investissement qui est fait sur cette infrastructure logicielle.
Bruno:
Est-ce que c'est un contexte qui est pour toi très spécifique du développement logiciel, au sens, entre guillemets, client lourd, ou c'est un truc qu'on peut retrouver aussi dans des contextes de SaaS, voire même de développement plutôt orienté web ?
Jean-Christophe:
En fait, c'est un pattern, cette pyramide, cette fameuse pyramide et cette infrastructure logicielle, on la retrouve à plusieurs étages. C'est ça qui est étonnant, c'est que tout d'abord je me suis rendu compte évidemment que c'était chez tous les éditeurs qui faisaient du client lourd on va dire, mais on a aussi nous, on a aussi, des outils SaaS, on a aussi des sites web on a aussi des choses comme ça, mais on a aussi le problème c'est pareil, et puis ça a été encore même plus loin c'est que je me suis dit tiens c'est bizarre parce que on adresse les problèmes des éditeurs mais quand on remonte un petit peu parce qu'on fait aussi l'intégration, parce que quand on intègre nos outils logiciels dans des processus, il faut faire de l'intégration, on se rend compte que quand Quand on regarde un industriel qui crée un processus, il est en train de se créer une sorte de méta-système au-dessus, créé à partir d'une composition d'outils, de logiciels, d'outils maison, etc. Et lui aussi, il est en train de faire de la composition, il est aussi en train de se faire une sorte de pyramide avec du métier et de l'infrastructure logicielle. Alors pas au même niveau. On retrouve les mêmes patterns, c'est-à-dire qu'il y a énormément de ressources, au moins 80% de ressources, 70-80% de ressources qui sont investies dans l'infrastructure, pour pouvoir obtenir les fameux 20-30% de métiers.
Bruno:
Est-ce que tu pourrais nous donner un... T'as évoqué le fait qu'on utilise des frameworks, un tas de librairies pour essayer de tacler une bonne partie de ces problèmes, mais qu'on continue à faire ce que t'as pas eu de cette infrastructure logicielle. Est-ce que tu pourrais nous donner un exemple concret d'un truc qu'on fait au-dessus d'un framework qui pour toi n'est pas dans la catégorie métier mais reste dans cette partie infrastructure logicielle ?
Jean-Christophe:
J'en ai plein. Ce qui est intéressant, j'en ai toujours un qui est celui que je ressors tout le temps, donc ceux qui me connaissent, ils ont dit Iradot, mais je parle souvent du une doux redoux, le fait de l'historisation, une doux redoux, mais il y en a des tonnes. Celui-là, il est un peu, je dirais, typique parce qu'il me fait rire à chaque fois que je le rencontre. En fait, tous ces problèmes-là, ce qui est intéressant, c'est qu'ils ne sont pas si simples que ça à décortiquer, parce que souvent, ce que je constate, c'est qu'il y a une porosité entre le métier et l'infrastructure. Comme je l'explique là, on se dit, tiens, je vous lis, il y a une petite pyramide en haut avec le métier, puis en dessous, il y a un socle avec l'infrastructure logicielle. Ça paraît tout bête et tout simple. Alors, certains architectes arrivent à faire ça, et c'est très propre et ça marche très bien. Mais bien souvent, ce n'est pas juste un socle bien propre, il y a interpénétration entre les deux univers, et ça fuite. Il n'est pas rare qu'on retrouve du métier dans l'infrastructure logicielle et l'adversaire. Et là, ça se gâte.
Bruno:
En vrai, est-ce que tu as déjà vu des contextes où on arrive vraiment à avoir une séparation claire, nette entre ces deux éléments-là ?
Jean-Christophe:
C'est pas simple. Peu.
Bruno:
Moi, ma réponse, c'est toujours la même. La théorie est toujours vraie, sauf dans la pratique.
Jean-Christophe:
C'est très rare. On le voit vraiment sur des gens qui ont beaucoup de temps et qui sont acharnés et qui veulent mettre une limite propre, ça arrive, ça arrive, je ne veux pas dire que ça n'arrive pas, mais le cas... Pourquoi ça arrive peu, en fait ? Parce que quand on est dans le cycle de développement d'un logiciel pour répondre à un besoin métier. Mais qui va investir sur l'infrastructure logicielle ? Le client, lui, il s'en fout. Il a besoin de son métier. Donc, à un moment donné, le développeur a dit, j'y vais, il y va, mais sauf qu'il va passer 70 à 80% de son temps dans l'infrastructure logicielle. Et là, il va réinventer des concepts, À chaque fois. Sauf que dans l'infrastructure logicielle, il y a des problèmes qui sont durs et qui devraient être résolus une fois pour toutes. Or, ces problèmes, chaque équipe de dev les redéveloppe à chaque fois, les réinvente. Alors, il y en a qui sont plutôt chanceux, qui le font bien. D'autres qui sont moins chanceux, qui le font moins bien. Il y en a qui battent, qui n'ont pas le temps. Et là où on devrait cycler pour obtenir de la qualité, on ne cycle pas, on n'a pas le temps. On le fait une fois, puis après, on s'occupe du métier. Et là on commence à créer de la dette à la fois dans le métier mais surtout, et c'est plus grave, dans les 70% de codes de l'infrastructure logicielle donc là il y a quelque chose, il y a une sorte d'antipatente qui apparaît et je me dis mais on est tous en train de faire quelque chose de bizarre, on est tous en train de réinventer quelque chose sur lequel on devrait capitaliser plutôt que de réinventer alors je suis d'accord, il y a des frameworks, des outils, ça aide mais c'est pas suffisant.
Bruno:
Je vois bien parce qu'effectivement l'exemple de le fait de la simple commande de faire un annulé Ctrl-Z ou Pomme-Z ou pouvoir réappliquer quelque chose, ça paraît effectivement quelque chose d'évident pour tout le monde mais très vite en tant que dev tu réalises en fait tout ce que ça engrange en termes de dev pour réussir à faire tout ça je pense qu'on pourrait mettre dans la même liste des notions de notification par exemple sur une application, mais en fait ce que je me dis aussi c'est peut-être que dans la ce qui rejoint un peu ce sujet de porosité entre le métier et la l'infrastructure logicielle c'est que souvent ces sujets là en fait ils sont plus comme c'est demandé par des clients ça devient entre guillemets une fonctionnalité et donc c'est approché de manière métier là où effectivement en fait tu as raison c'est que si on reprend un peu de recul on se dit bah en fait faire un contrôle z est, Ce n'est pas une fonctionnalité, normalement, c'est la base. Donc, ça devrait être effectivement quelque chose de très disponible de base partout.
Jean-Christophe:
C'est-à-dire que si je suis développeur, je dois faire du métier et que j'ai une infrastructure toute faite qui m'apporte cette fonctionnalité directement, normalement, je suis censé être content. Sauf si vraiment, j'ai envie de le faire moi-même. Mais normalement, si on peut économiser ce travail-là et avoir quelque chose de fiable et de robuste sur lequel s'appuyer pour le faire, non seulement le client va être content parce qu'il l'aura, et ça va pas être bâclé par le développeur parce que souvent ce que je vois c'est quoi c'est j'ai besoin de telle fonction métier oui oui hop on le fait rapidement on livre, Mais le client dit, mais je ne comprends pas, je n'ai pas une doux, redoux, il faudrait me le faire. Ah oui, bon, je le ferai plus tard, ce n'est pas la priorité, oui. Et plus on tarde, plus c'est dur de le faire finalement, parce que ce n'est pas si simple que ça de le prévoir dans l'application. Alors, il y a des cas où c'est trivial, puis il y a des cas où c'est absolument infernal. Un petit exemple tout bête, c'est, vous prenez tout simplement Excel, vous avez plusieurs feuilles de calcul dans le même document, et le Hindu, est-ce qu'il est juste dans une feuille, ou est-ce qu'il est global à l'application, et quand vous faites Hindu, vous rebasculez d'une feuille à l'autre pour suivre toute la trace de vos modifications à travers le document global. Donc c'est des questions qui sont très intéressantes à se poser et justement ces problèmes qui paraissent pour certains très complexes ou très difficiles et pour d'autres extrêmement simples il faut s'en méfier parce que souvent c'est ce que j'appelle des blobs c'est à dire des paquets de nœuds qui mélangent plusieurs choses et quand on veut les attaquer frontalement mais on se plante et il faut prendre du temps, décortiquer les choses et comprendre comment ces choses là fonctionnent et comment on peut les implémenter de manière élégante.
Bruno:
Oui parce qu'en plus si on fait tout ça de manière approximative en fait tu te rajoutes de la dette technique donc tu te rajoutes cette viscosité au global sur la vie de ton projet.
Jean-Christophe:
Exactement, et du coup on a une dette technique d'infrastructure qui se mélange à une dette technique de métier, je pense que c'est suffisant d'en avoir une côté métier c'est pas la peine de s'ajouter celle du côté infrastructure, si on pouvait l'éviter ça serait pas mal.
Bruno:
Après t'as évoqué un sujet, t'as eu plutôt une petite phrase que je trouve intéressante quand on parlait de comment est-ce qu'on peut implémenter un sujet de undo redo ? C'est que t'as dit à un moment il y a certains devs qui se disent on va le faire nous même, est-ce que c'est pas aussi un problème je trouve que j'en ai déjà parlé plusieurs fois sur ce podcast mais je trouve qu'on a une ambivalence chez les développeurs et développeuses c'est que parfois il y a des trucs qu'on a envie de faire nous même, et tu vois par exemple tu prends une plateforme comme WordPress, elle est beaucoup décriée parce que les gens disent bah en fait moi une interface admin je peux la faire je peux la faire mieux que WordPress, je sais faire un moteur de bloc c'est facile machin et donc on a envie de faire les choses nous même et on aime pas quand on a un truc qui nous fait les trucs tout fait parce qu'on a l'impression de plus rien avoir à faire et en même temps, on souffle beaucoup quand on se retrouve à devoir faire des choses qu'on a l'impression d'avoir déjà fait, x fois et qui nous paraissent ennuyeuses quoi.
Jean-Christophe:
C'est intéressant ta question en fait, en fait moi ça évoque pour moi un peu l'opposition entre le low-code, no-code et le développeur qui fait tout, en fait. Cette opposition-là. C'est-à-dire, quel est le boulot du développeur, finalement ? C'est évident qu'un développeur, quand on lui donne un low-code, si c'est un développeur costaud, il va dire « Mais non, moi, je ne suis pas de cette trempe-là, moi, je développe, ça, c'est pour les mangeurs de quiches, j'en sais rien, enfin, quelque chose comme ça, quoi. » Bon. Le low-code, comme je crois qu'on avait parlé, le low-code, le low-code, pour moi, le plus développé au monde c'est Excel, tout bêtement, c'est une plateforme fantastique qui permet en quelques minutes de faire des choses que si on doit les coder à la main ça sera moins facile, bon on a l'IA aujourd'hui mais... Donc ça amène des choses mais par contre ça amène de la rigidité ça amène un cadre c'est une sorte de framework justement dans lequel on vient rentrer des choses et tout le reste est mâché, tout le travail est mâché, donc dans notre approche on aime bien le développement donc il n'est pas question de faire un low-code. Il est question de dire, ok, on reste dans le développement, mais est-ce qu'on peut s'économiser un travail et s'appuyer sur des composants logiciels qui vont nous permettre de construire des, tu parlais de cathédrales qui viennent foutoir, mais des belles cathédrales, des choses extraordinaires ? Voilà, c'est ça la question. Parce que si on veut tout construire, si on veut tout maîtriser, on ne peut pas. En fait, dans une vie, ça ne suffit pas. Donc le but c'est de mutualiser, d'avoir des composants qui soient extrêmement, ou une plateforme plutôt que des composants même, qui soient extrêmement robustes, élégantes, sur lesquelles on va s'appuyer en tant que développeur dans une logique de développement et d'architecte logiciel, on va construire quelque chose. Mais par contre je ne vais pas redévelopper à chaque fois réinventer des choses, et en plus je vais les réinventer pas forcément de manière idéale, qui sont nécessaires au développement de mon métier et une vraie question qui se pose c'est finalement est-ce que je suis développeur métier ou développeur infrastructure et aujourd'hui beaucoup de développeurs font tout. Mais je trouve que c'est bizarre parce que un développeur infrastructure l'infrastructure c'est un métier l'infrastructure logicielle est un métier c'est très dur, c'est très très dur comme métier Ça demande extrêmement beaucoup de connaissances, de savoir-faire et d'être focus sur ça. Et c'est tellement large et complexe qu'il y a même des spécialités dans ce métier de développer de l'infrastructure. Donc dire à quelqu'un « tu vas faire le métier mais en plus tu vas tout gérer, tu vas gérer, tu vas construire une infrastructure, etc. », je trouve que c'est contre-productif en fait.
Bruno:
Donc en fait, avec Digital Substrate, vous mettez à disposition justement toute cette infrastructure logicielle pour permettre aux équipes de se concentrer uniquement sur ces fameux 20% de métiers ?
Jean-Christophe:
Oui, c'est ça. En gros, l'objectif, c'est de fournir un environnement de développement et de faciliter la construction finalement de toute la stack logicielle, finalement, en ayant une base solide qui amène le plus possible aux développeurs. Alors, on continue à ajouter des choses dedans parce que c'est énorme. Là, il y a vraiment de quoi travailler. Il y a une roadmap qui est immense. Mais bon, on parlait, typiquement, on commence par, on aime bien le parting data-centrique. Donc, on commence par les data parce que les algorithmes, ils s'expriment sur des data. Donc, quand on néglige les data, ça se passe mal au niveau des algorithmes. Donc, on commence par la data. et dans la data il y a énormément de choses à faire déjà, commencer à mettre ça propre à dire ok, comment je manipule ma data dans mon infrastructure, qu'est-ce que l'infrastructure me met à disposition, et là par exemple le truc tout bête c'est comment se réalise de la data, ok, comment ma data c'est quoi les schémas est-ce que c'est fortement typé, pas fortement typé, c'est un problème aussi intéressant, beaucoup aiment le non typé parce que c'est souple mais quand on est dans l'informatique industrielle, ça peut poser des problèmes à l'exécution.
Bruno:
J'ai quand même l'impression que l'absence de typage devient de plus en plus mal vue. Il y a peut-être une raison. Il y a une raison, ça je suis d'accord.
Jean-Christophe:
C'est toujours pareil, on gagne à court terme, mais on perd à long terme. C'est-à-dire que le typage, il amène quelque chose. Donc justement, est-ce qu'on... Nous, on a pris le parti pris justement très fort de créer une base solide dans laquelle les schémas données sont très fortement typés. Donc du coup, on peut on peut maîtriser au moins ces propriétés-là dans l'infrastructure. Ensuite, comment on va s'interfacer avec différents langages ? Est-ce que... On est agnostique, c'est-à-dire que, alors j'utilise ce terme-là dans le mode informatique, parce que c'est un terme qui est un peu, en termes de sémantique, qui a beaucoup de sens. Mais est-ce qu'on est neutre vis-à-vis des langages ou des environnements de développement ? Ça serait pas mal, parce que si on propose quelque chose qui est juste dans Java, ça va pas. Donc comment est-ce que nos concepts se projettent bien dans toutes ces plateformes, dans tous ces langages, pour augmenter n'importe quel développeur, quels que soient ses choix ? Est-ce qu'on est dans la collaboration ? La collaboration avec un C majuscule est-ce qu'on facilite la collaboration ? Parce que la collaboration avec un C majuscule pourquoi ? parce que la collaboration c'est ce qu'on fait en permanence, nous les humains, c'est plein d'humains qui collaborent tout le temps, surtout les développeurs collaborent au sein de leur écosystème pour produire un écosystème logiciel, les utilisateurs collaborent dans les process et les systèmes donc la collaboration il y en a partout, donc comment l'écosystème, comment le l'infrastructure digitale logiciel va nous aider à collaborer ? Ça c'est une question fondamentale et là il y a un travail titanesque à faire après on continue on va dire tiens on parlait d'une doure doux mais ça c'est juste la partie visible de l'iceberg. Parlons de l'historisation j'ai un système dans quel état il était à telle date ? Est-ce que j'ai une traçabilité ? Est-ce que je peux démontrer par où est passé mon système ? Est-ce que je peux dire, est-ce que je peux certifier que mon système à telle date était dans tel état ? Est-ce que je peux revenir à cet état-là ? Moi, comme je dis, l'effet de bord, c'est le pire ennemi d'un système fiable et stable. On aime beaucoup le fonctionnel, on n'aime pas les effets de bord, mais les développeurs adorent les effets de bord dans le métier, c'est très pratique. Alors, si on est dans le fonctionnel, c'est parfait, mais l'effet de bord, c'est bien, c'est pratique. Seulement, si on travaille en effet de bord et en système, en service asynchrone, qu'est-ce qui se passe ? On fait des systèmes extrêmement complexes qui sont très, très durs à maîtriser. La synchronicité dans les systèmes informatiques, c'est ce qu'il y a de plus complexe à gérer. Et on croit qu'on y arrive. Effectivement, encore une fois, ça simplifie à court terme les problèmes. Ça semble les simplifier. Et puis, à terme, c'est inexplicable. On ne comprend pas ce qui se passe. Ce n'est pas débugable. Donc, comment on résout toutes ces questions-là ? Voilà, c'est là qu'on commence à toucher. Je n'ai pas parlé une seule fois de métier autre que du métier de l'infrastructure logicielle. Et je pourrais en parler comme ça pendant deux heures. Les domaines sont vraiment super importants.
Bruno:
Je suis un peu sceptique quand tu dis que les développeurs et développeuses aiment les effets de bord. C'était ironique ?
Jean-Christophe:
Non, quand je dis effets de bord, je vais préciser. Je pense que les développeurs adorent CRUD.
Bruno:
Alors là, encore une fois, je suis... Tu n'es pas d'accord ? Dans le sens où, en fait, en tout cas, moi, dans les gens que je croise régulièrement, on a l'impression qu'un CRUD, c'est... Enfin, c'est un CRUD, quoi. C'est facile. Ce n'est pas intéressant, quoi.
Jean-Christophe:
Oui, c'est peut-être facile. Mais je veux dire, si tu prends un développeur qui arrive et qui doit implémenter du métier... Probablement beaucoup plus à l'aise avec du crud par exemple si on parle de data il va être plus à l'aise sur du crud que si on lui dit là tu vas être dans un parking fonctionnel et puis il va dire, pour moi la grande masse des développeurs fonctionne dans l'impératif et dans, l'effet de bord, la modification live des datas.
Bruno:
Mais donc quand tu parles d'effet de bord tu ne parles pas d'un effet de bord indésirable Non.
Jean-Christophe:
Non, non, je ne parle pas d'un état de bord des erreurs. Je parle de plutôt j'ai une data, je la prends, je la modifie, je la rends. C'est-à-dire, en fait, le principe d'un processeur. Il y a une RAM, je modifie la RAM et puis je la rends dans l'état dans lequel j'ai modifié. Le problème de ça, c'est que ça crée des systèmes qui mutent en permanence et qu'on ne maîtrise pas. Surtout si on met de la synchrone là-dessus. L'idée qu'on a développée chez Digital Substrate c'est de dire, Read Only lecture seule c'est à dire qu'on ne veut pas que le système soit modifié in place toutes les bases données, toutes non mais 97% des bases données de la planète sont en mode je modifie in place la data, je fais un select, boum, je update le champ terminé, c'est modifié sauf que dans le milieu industriel, on a envie de garder l'historique des choses, on a envie de savoir ce qui se passe, donc même un algorithme métier il a besoin, d'avoir une donnée robuste sur laquelle s'appuyer. Donc, le fait de garder une traçabilité de ce qui se passe, c'est super essentiel. C'est très puissant d'un point de vue mathématique pour construire des algorithmes robustes. Dès qu'on rentre dans l'asynchronicité et dès qu'on rentre dans ce que j'appelle l'effet de bord, c'est-à-dire la modification à tout va de la data, des états en fait, on crée des systèmes qui sont inextricables en termes de complexité du côté métier. Au début, c'est facile, ça va vite. Et puis très vite, ça s'embaube et ça ne marche plus.
Bruno:
Ok j'en vois Quelle différence on pourrait faire du coup est-ce que Digital Substrate c'est un framework au final ou ?
Jean-Christophe:
Alors je me méfierais du mot framework parce que j'ai eu une tendance à l'utiliser à tort et à travers si on regarde la définition un peu académique du framework c'est finalement un système qui définit des points d'accrochage dans lequel typiquement, on pourrait presque dire qu'Excel c'est un framework parce qu'il y a des cases, des cellules dans lesquelles on vient mettre le code et tout ce qui est autour de ces cellules-là est complètement sous contrôle d'Excel. Donc c'est ça, la définition académique du framework. Donc ce n'est pas un framework. Aujourd'hui, on est arrivé à un niveau où on dit que c'est plutôt un data OS, c'est-à-dire un système d'exploitation de la donnée qui va prendre en charge toute la gestion de la data, et même plus, puisque ça va prendre en charge aussi tout ce qui est service, et qui va amener aux développeurs une plateforme robuste pour développer dessus des applicatifs. Mais des applicatifs qui vont du coup cohabiter et collaborer. En tout cas, qui auront une facilité pour collaborer parce qu'ils vont être comme des add-ons, en fait, sur le DataOS. Un peu comme si vous prenez un vrai système d'exploitation, mettons Linux au hasard, l'OS nous libère d'énormément de choses. Il définit des standards, des façons de... Voilà, les IPC, etc. Ça définit plein de systèmes, des bus. Et après, les applications ne sont plus que des plugins dans ce système-là, et ils sont libérés de beaucoup de choses. Je ne dirais pas de tout, mais de beaucoup de choses. Donc là, c'est un peu la même image. C'est-à-dire, on arrive avec une sorte de data OS qui peut s'installer. Localement sur une machine, ou alors au sein d'un logiciel, ou alors même au sein d'un service dans une entreprise, et qui va être distribué. Et du coup, tout ce qui se greffe dessus va pouvoir bénéficier de ce data OS, et aura une sorte d'abstraction de où se passent les choses, où sont les données, et un langage commun pour travailler et communiquer. Et c'est ce qu'on appelle, le résultat de ça, c'est ce qu'on appelle le digital backbone, c'est-à-dire une sorte de colonne vertébrale qui nous permet de travailler sur une plateforme qui est uniforme, je dirais, standardisée en quelque sorte.
Bruno:
Ok. Et donc, tu parlais aussi du côté très agnostique des différents langages, c'est-à-dire que du coup, ce Digital OS est dispo dans plusieurs langages ou peut s'interfacer avec tous les langages ?
Jean-Christophe:
Alors aujourd'hui, on ne supporte pas tous les langages, on avance, c'est un peu de boulot quand même, mais il est fait, il est pensé dès le départ pour être neutre d'un point de vue langage. Donc aujourd'hui, on a le C++, on a Python. Et on avait aussi à un moment donné C-Sharp, on imagine Java, enfin, ce n'est pas très compliqué d'aller sur ces langages-là, ça va être une projection, donc ça, c'est une question de temps, je dirais, de le mettre en place. Et pourquoi est-ce qu'on est neutre vis-à-vis des langages ? Parce que je remarque que très souvent, justement, ce qu'on appelle des frameworks ou ce qu'on appelle des bibliothèques, sont très, très marquées, langages, elles sont complètement intégrées. Donc chaque langage, encore une fois, vient non pas seul, mais avec son petit écosystème d'infrastructures logicielles, que ça soit Python, que ça soit même C++, C++ on a la STL, Python on a toute la mécanique d'objets, etc. Qui est dessous, de gestion d'objets, etc. et d'intelligence de l'interprète. Donc c'est pas juste un langage c'est un langage et un système de gestion un paradigme qui va avec et ils ont tous le leur mais qui sont différents, donc c'est un peu le bazar comment on fait pour passer de l'un à l'autre comment on fait collaborer tout ça donc. Le coeur du système de notre dataOS, Ça commence par une couche très bas niveau, qui est une sorte de kernel en quelque sorte, qui s'appelle Viper, et qui va en fait définir un standard sur la manipulation des données et des API, on va dire. Et toutes sortes d'outils utilitaires pour faire de l'inter-process. Ça va générer une couche, une sorte de bibliothèque standard, on va dire, et qui est bien sûr accessible dans n'importe quelle plateforme. On doit porter dans n'importe quelle plateforme cette couche data.
Bruno:
Donc en fait, votre système est recodé dans les différents langages que vous supportez.
Jean-Christophe:
Ça, c'est notre job.
Bruno:
Et que du coup, tu peux embarquer dans toute ton application.
Jean-Christophe:
Exactement. C'est ça le principe. Au-dessus de ça, on a d'autres outils qui viennent se mettre. On a des couches qui montent comme ça de plus en plus en fait c'est pour ça que ça ressemble un peu à un DataOS on a des couches de plus en plus haut niveau qui remontent et qui fournissent des services de plus en plus importants par exemple au dessus on va avoir une sorte de base de données qui s'appelle Commit et qui est une base de données qui est en lecture seule et qui ne fait que stocker, des modifications, en différentiel les modifications sur les datas donc en fait on a une sorte de, un peu comme Git on a une sorte de journal qui est capable de retracer toutes les modifications qui ont été faites sur la data, et de réévaluer finalement l'état du système à n'importe quel moment. Et ça, elle le fait sur en plus des datas qui sont très fortement typées, parce que là on a voulu que ça soit, pas du JSON quoi, on a un truc où ça soit vraiment, c'est fort, c'est typé, donc ça ressemble beaucoup à ce qu'on trouverait dans un langage type Java, C++ ou autre, là on a des types assez... On a un langage qu'on a développé spécialement pour ça, de description, qui s'appelle le DSM, et avec quelques concepts j'imagine.
Bruno:
Qu'il y a descriptions.
Jean-Christophe:
Esquema et, digital substrate model c'est tout bête j'avais le M avec model on met ce qu'on veut dedans mais en fait, je ne vais pas rentrer en détail là-dedans mais je trouve qu'il y a des choses assez intéressantes dans ce dans ce langage et une des particularités par exemple c'est que les schémas qui sont définis sont complètement peuvent être fusionnés. Je parlais tout à l'heure de collaboration entre les développeurs, de développeurs qui définissent leur schéma en distance, chacun de leur côté. On va être capable, nous, de fusionner les schémas sans clash. Et donc, du coup, de créer une base qui unifie, réunit, finalement, deux schémas.
Bruno:
Et qui permet d'adresser les sujets, les deux personnes.
Jean-Christophe:
Vous prenez le schéma de A, le schéma de B, et M.C. Va être capable de composer A et B pour faire quelque chose de plus riche au-dessus.
Bruno:
C'est cette notion d'historisation. Donc, si j'ai bien compris, ta data, elle n'est pas modifiée en tant que telle. Mais donc tu vas stocker toutes les modifications qui ont été apportées sur une data tu parlais sur un modèle similaire à Git, est-ce que ça veut dire que quand moi j'accède à l'information t'es obligé de réexécuter entre guillemets toutes les modifications qui ont lieu pour avoir la version finale, ce qui j'imagine peut amener à une, certaine latence ?
Jean-Christophe:
Oui alors ce qui est intéressant, alors ça c'est de l'optimisation on peut cacher les valeurs, en fait nous ce qu'on fait en plus c'est que quand tu accèdes à une valeur, on fait bien attention à ne ne gérer que les opérations qui ont été nécessaires pour calculer cette valeur, ce qui, en général, il n'y en a pas beaucoup, en fait, ça va assez vite. Si on devait réévaluer tout l'état du système, ça serait catastrophique. Mais en fait, on fait ça de manière lésie, en fait. On fait attention. Donc, il y a plein de propriétés intéressantes. Quand on est sur des données qui sont read-only, et qui sont fixes, et qui ne font que grandir, on a plein de propriétés mathématiques super intéressantes pour créer des caches, pour optimiser, c'est super agréable. Quand on est sur des choses qui bougent tout le temps, c'est super pénible. Donc ça c'est une propriété du système et c'est tellement Red Only d'ailleurs que le journal qui permet de stocker toutes ces modifications différentielles en fait c'est une blockchain donc ça veut dire qu'en fait, c'est hyper intéressant parce qu'on a un journal, on ne met pas ça dans une blockchain de crypto c'est une blockchain dans le sens où il y a quand même une certaine sécurité dans la chaîne de valeur on ne peut pas facilement intervenir et modifier dans le journal quelque chose Vous.
Bruno:
Reprenez la mécanique.
Jean-Christophe:
Mais pas forcément.
Bruno:
La technologie en tant que.
Jean-Christophe:
Telle Exactement Ok.
Bruno:
J'avais une question qui m'a échappé. C'était lié à ces sujets de... Alors déjà, sur le... Parce que... Sur ce que vous fournissez, pardon, j'arrive sur ma question. Ce que vous fournissez comme infrastructure logicielle, il y a effectivement plein de choses qui paraissent super utiles, mais on n'a pas forcément besoin de tout ça. Est-ce que du coup, tu peux aussi morceler en disant, en fait, moi, je prends ça... Parce que ça représente de la code base, en fait, qu'il faut, mine de rien, embarquer. Est-ce qu'on peut réussir à se dire, je ne veux que ça pour limiter la taille de mon...
Jean-Christophe:
Oui, en fait, c'est un peu comme un système d'exploitation. Tu as énormément de choses, peut-être un peu trop d'ailleurs. Il y a certains systèmes qui gonflent, qui n'arrêtent pas d'enfler, donc c'est insupportable. Nous, en fait, on est vraiment en mode composition, c'est-à-dire que c'est plein d'outils et tu vas être capable d'utiliser certains outils et pas d'autres. Même, tu peux ne prendre que ces outils-là. Si tu veux vraiment réduire la surface logicielle, tu n'es pas obligé de t'embarquer toute la mécanique. Ce n'est pas très large, en fait. Il y a un peu de code quand même mais c'est pas non plus c'est pas un monstre, c'est ça que je veux dire Ok.
Bruno:
J'ai retrouvé la question tu parlais tout à l'heure que chaque langage amène un peu son paradigme dans sa manière de manipuler la data, dans sa manière de concevoir les opérations est-ce que ça veut dire que si on utilise, Digital Substrate du coup c'est un nouveau paradigme c'est à dire que du coup si on fait du Python on sera plus vraiment dans du Python et donc c'est une autre manière d'approcher les choses.
Jean-Christophe:
Excellente question. Donc en fait pour continuer un petit peu l'histoire de ce qui se passe dans ces couches de ces différentes couches de ce data OS en quelque sorte, quand on remonte on finit par trouver une sorte d'évaluateur qui va être capable de calculer des valeurs à des états donnés et on va comiter des modifications sur ces valeurs. Tout ça c'est fait avec un sur Viper, tout est dynamique. Il n'y a rien de statique, tout est dynamique. Donc on peut étendre les schémas dynamiquement, on peut faire plein de choses de manière dynamique. Le problème, c'est que. On s'est vite rendu compte qu'utiliser cette machinerie dynamique dans n'importe quel langage, c'était un petit peu infernal. Alors, c'est extrêmement puissant d'un point de vue infrastructure, ça permet de faire des tas de choses incroyables, mais à l'usage, pour faire un petit bout de code métier tout bête, on se dit, mais non, c'est horrible. D'ailleurs, c'est très rôle parce que Laurent, qui est le tech leader chez nous, qui a codé la cathédrale, on va dire, de Digital Substrate, lui-même, quand il a voulu utiliser son système, il dit, moi, je refuse de coder. C'est trop compliqué pour faire un petit bout de code comme ça, ça va pas. Et là l'idée a été de dire mais ok, on veut le dynamique mais on veut pas être en train de vérifier dynamiquement si ma propriété elle est là ou s'il y a telle chose ou si... Non, ça c'est pas intéressant, c'est trop compliqué. Ça peut s'avérer nécessaire dans certains cas, dans certains cas où on a du métier très dynamique et on a besoin, je sais pas, par exemple on a un débugger qui rentre dans le système et qui permet de débugger toute la traçabilité des datas, les modifications, etc. Lui, il est purement dans le dynamique.
Bruno:
Forcément.
Jean-Christophe:
Il ne peut pas être statique. Mais les développeurs, quand ils font du métier, ils aiment bien avoir un schéma, et puis après, avoir du statique, comme il l'aurait codé à la main. Donc en fait, c'est là qu'intervient, Kibo. Kibo, c'est un robot générateur de code qu'on a développé sur DSM, qui est le langage de description des schémas. Et en fait, lui, il est capable de dire, OK, vous voulez travailler sur ce sous-ensemble de schémas d'information. Nous ce qu'on peut faire, ce que je peux faire moi en tant qu'IBO, vous me dites quelle plateforme vous voulez utiliser, Python, C++, Java, etc. Et je vais être capable de vous produire une bibliothèque. Qui va faire l'interface finalement entre vous, en mode statique qui va vous produire une interface statique de votre côté mais qui dessous va piloter le dynamique ça veut dire que vous allez avoir alors on va utiliser le mot framework c'est pas le bon mot peut-être mais si un framework une sorte de framework data, qui va permettre d'adresser. Le data OS et les datas dans le data OS avec le schéma qu'on a sélectionné et là pour le développeur il est complètement dans son paradigme c'est à dire qu'on a fait l'effort de dire ce qui est présenté au développeur c'est ce qu'il a l'habitude de faire lui quand il développe son framework data dans son langage dans son paradigme donc du coup c'est à nous de nous adapter c'est à Digital Substrate d'apporter quelque chose qui est conforme aux attentes du développeur c'est pas au développeur de s'adapter J'aime bien ce paradigme-là, de dire, c'est pas, j'aime pas, par exemple, quand l'industriel doit s'adapter à un logiciel et il fait rentrer un rond dans un carré. Ces data, ben non, ces data, c'est les data d'éditeur, finalement. L'éditeur capture ses informations et c'est à l'utilisateur de, finalement, faire rentrer sa data dans le truc. Là, c'est pareil. On a un développeur, il a un savoir-faire, c'est pas à lui de s'adapter, c'est à nous de nous adapter pour venir dans son monde. Donc Kibo va générer ce framework et le développeur va pouvoir utiliser quelque chose de complètement statique en mode crud, si on veut on peut faire autre chose mais en mode crud typiquement avec une API toute bête des sets, des get etc ça s'est généré automatiquement, Et par contre, dessous, on a toute la machinerie, toute la puissance du DataOS, qui va lui régler des problèmes qu'il n'imagine pas, en fait.
Bruno:
Oui, hyper intéressant. Donc, en fait, ce robot, au final, tu parles d'un robot qui génère du code. Alors, il y a peut-être plein de gens qui imaginent des LLM qui vont aller générer du code à la volée, mais au final, on est plus sûr. Ce n'est pas tant du... Ce n'est pas du code qui va être généré en mode je veux telle fonctionnalité, et du coup, il génère le code. C'est presque plus une interface au final le fait qu'elle soit générée et pas tant un sujet c'est juste que ça permet d'avoir une interface qui est spécifique à ta data contrairement à, une interface traditionnelle qui se veut plus agnostique de la data qu'est derrière.
Jean-Christophe:
Et surtout dynamique par exemple prenons du C++ typiquement ou tout autre langage, très fortement typé tu vas avoir la complétion tu vas avoir tout est statique donc tu te retrouves dans ton univers et c'est super agréable à utiliser et tu te rends pas compte que dessous il y a une machinerie incroyable qui va prendre en charge tout ça et transformer ça différemment tu fais un set sur une propriété mais dessous, tu ajoutes un élément dans un ensemble et dessous on va stocker le différentiel, ça va être fait tout va être, comment dire simplifié pour le développeur. Il reste dans son monde, c'est simple. On se charge de la complexité dans l'infrastructure. C'est ça le but, c'est libérer le développeur de cette complexité. Parce que l'infrastructure, elle doit être, pour pouvoir amener toutes sortes de propriétés à l'avenir, comme par exemple par l'historisation, le nous, la collaboration, etc. Elle doit faire un certain nombre de choses auxquelles le développeur ne pense pas au début quand il commence à coder.
Bruno:
Clairement.
Jean-Christophe:
Donc là, on le met tout de suite dans son monde où il a l'habitude de travailler. Et plus tard, quand il aura besoin, ou tout de suite, quand il aura besoin de fonctions plus élaborées pour son environnement fonctionnel, il pourra compter sur le système qui est en dessous.
Bruno:
J'essaie de voir de tout ce que tu as raconté que je trouve hyper intéressant et assez fascinant est-ce qu'au final l'objectif avec Digital Substrate c'est de permettre que toute application devienne un CRUD et donc simple comme un CRUD au final ou est-ce que c'est de faire en sorte qu'un CRUD, reste un CRUD dans le sens où c'est ce que tu viens de dire au final en fait faire un CRUD c'est facile mais très vite, en fait on t'ajoute des demandes qui font que tu te rajoutes de la complexité et donc de la viscosité. Enfin, tout ça, on l'a déjà cité. Donc, tu vois, est-ce que DJI Subtrade, c'est tout transformer en CRUD ou faire qu'un CRUD reste juste un CRUD ?
Jean-Christophe:
Alors, je ne voudrais pas réduire le DataOS au CRUD. Le CRUD, c'est une façon d'attaquer les datas.
Bruno:
OK.
Jean-Christophe:
Mais par exemple, on peut parler de tout ce qui est API. Si on veut définir des services, comment on fait sur des datas ? On dit, tiens, j'ai les datas, c'est bien, c'est la première couche, mais au-dessus, on a des services. Donc, comment on va définir les services ? Donc c'est pareil, la couche d'infrastructure doit être capable de définir des standards dans le langage des SM. On a de quoi décrire des services avec des API standardisés.
Bruno:
Des sujets d'authentification ?
Jean-Christophe:
En fait, tout sujet lié à l'infrastructure devrait pouvoir être pris en charge par cette infrastructure, par ce système. Donc aujourd'hui, on a effectivement un fonctionnel qui est ce qu'il est, mais qui est déjà très large, et qui ne cesse d'augmenter. Donc, aujourd'hui, on fournit, pour la partie data, une interface CRUD. On pourrait fournir d'autres choses, mais celle-là, elle est fort pratique quand on veut faire un petit peu de fonctionnel. Et par exemple, quand on a défini son modèle de données et que ça génère automatiquement une interface CRUD dessus, ce qui est intéressant, c'est qu'on va avoir automatiquement la production du framework dans chaque plateforme, c'est-à-dire en Java, en C++, en Python. Et instantanément, on a en Python la capacité de modifier le jeu de données. Mais c'est un jeu de données fortement typé, Ça veut dire qu'en Python, il a fallu faire ce qu'il fallait pour que Python soit quand même contraint d'utiliser des jeux de données typés. C'est quand même pas la grande force de la chose. Donc tout est géré. Par exemple, les systèmes d'exception et d'erreur sont très importants dans ces systèmes-là. On ne fait pas de la rigolade. Quand il y a quelque chose qui ne va pas, il faut que ça soit très vite remonté, que ça soit géré. Donc les systèmes de traitement d'erreur, c'est tout bête. Mais rien que cette chose-là, traiter correctement les erreurs et les exceptions, surtout dans des environnements hétérogènes, c'est l'enfer. Pour le faire bien. Donc, pour le faire bien, et surtout le faire en multiplateforme, il faut s'appliquer, il faut travailler. Là, il y a du boulot, quoi. C'est pour ça que quelqu'un qui fait un logiciel pour un métier, il a autre chose à faire que ça.
Bruno:
Mais d'ailleurs, du coup, c'est peut-être un peu surprenant, d'ailleurs, que vous fassiez le choix d'aller vers des langages qui ne sont pas forcément typés. Là, au final, pour un DataOS, le typage est quand même une fonctionnalité fondamentale, il me semble.
Jean-Christophe:
Oui, justement. L'idée c'est, on attaque du C++, du Swift, du Java, ou du JavaScript, du Python, voilà, en fait on s'en fiche, on peut attaquer n'importe quel langage, mais il faut qu'on soit capable de proposer dans le langage en question quelque chose d'agréable à utiliser pour les personnes qui travaillent dans ce monde-là. Ça veut dire quoi ? Ça veut dire que dans une équipe de développement logiciel, on pourrait avoir une partie de l'équipe qui travaille, mettons, en Java, et l'autre partie qui travaille en Python. Prenons un exemple simple, je développe un logiciel en Java et puis je le fournis à mes clients et ils ont presque immédiatement la possibilité d'écrire des plugins en Python pour étendre le fonctionnel. C'est fort pratique.
Bruno:
Ok, canon. Tu évoquais au début que le constat qui a mené à la naissance du digital sub-thread, c'est de se dire que il y avait effectivement un ensemble, il y a eu deux techniques qui s'accumulent, qui créent effectivement cette fameuse viscosité, et tu l'évoquais aussi très justement cette... On pourrait presque parler d'une tristesse des développeurs et développeuses, parce que c'est vrai que, c'est un sujet que je vois aussi souvent arriver, c'est qu'on se dit telle fonctionnalité, dans l'absolu, ça me prendrait une semaine à développer, mais dans le contexte où je suis aujourd'hui, ça va me prendre deux mois et c'est forcément déprimant quand on a ce genre de constats et au final, la décision que vous avez prise c'est de résoudre des sujets de dette technique avec encore plus de code d'une certaine manière.
Jean-Christophe:
En fait c'est un peu le parallèle avec un système d'exploitation, c'est à dire qu'on essaye d'extraire quand les développeurs s'il y a 1000 développeurs et qu'ils redéveloppent 1000 fois leur application il va y avoir une duplication enfin pas une duplication mais, on va réinventer 1000 fois cette couche d'infrastructure donc si on arrive à faire une couche d'infrastructure qui est, réutilisable, on a une factorisation en fait, et c'est là où il y a un gain c'est ça le but, c'est d'avoir un gain en qualité, un gain, on capitalise, ça devient de plus en plus costaud et on va pas s'amuser aujourd'hui on ne s'amuse pas à réécrire son système d'exploitation on pourrait, mais en bas qu'il y a, peut-être qu'on pourrait le.
Bruno:
Faire mais ça met un peu long quand même amusant, Ah zut, j'avais perdu ma dernière question, qui était pour... Ah zut, attends, on parlait de quoi ? Si je refais le fil, on parlait de quoi ? On était de résoudre la dette avec de plus de codes, et tu m'as dit quoi ?
Jean-Christophe:
Je t'ai dit qu'en fait, sur la partie plus de code, non, c'est pas plus de code, c'est moins de code. Parce que pour l'équipe de développement, finalement, elle, elle va s'appuyer sur le système. Donc techniquement, elle n'a plus que le code métier. Elle a très peu de code d'infrastructure. Donc du coup, elle va s'appuyer sur quelque chose qui va lui économiser, mettons, 70% du code d'infrastructure. C'est ça le but, le challenge, c'est ça. Donc lui apporter énormément de puissance de feu en termes d'infrastructure logicielle, tout en lui économisant 70%, donc c'est double gain.
Bruno:
Ma question, c'était là, pour terminer, on a évoqué tout à l'heure le cas de WordPress et de cette ambivalence chez les développeurs qui ne veulent pas qu'on fasse chose à leur place, mais qui ne veulent pas non plus refaire en permanence les choses. Dans quelle mesure est-ce que, ça va effectivement faciliter la vie des développeurs et développeuses ? Et à quel point aussi, est-ce qu'ils peuvent après aller parfois bidouiller dans le système pour y ajouter des choses qu'ils potentiellement qu'ils auraient envie d'améliorer d'une manière ou d'une autre.
Jean-Christophe:
Il y a toujours moyen, c'est un système qui est relativement ouvert, donc on peut toujours créer au-dessus, à côté, il n'y a pas de... Le but n'est pas d'enfermer, donc il y a toujours moyen d'ouvrir. Moi j'aurais tendance à dire, je le vois ce comportement, je l'ai entendu des gens dire, ah mais c'est mon boulot ça moi, d'écrire l'infrastructure, etc. Oui, ok, mais il y a tellement à faire du côté métier il y a tellement de belles choses à construire et aujourd'hui finalement l'énergie elle est bouffée à 80% dans l'infrastructure mais globalement, est-ce qu'on peut imaginer le coût que ça représente sur la planète ? Si on pense que 80%, 70% à 80% de l'énergie des développeurs, elle est dans l'infrastructure, ça veut dire quoi ? Et moi, je vois bien dans les cas industriels, dans la vie de tous les jours, mais il y a énormément de choses à faire, énormément de valeurs à construire, mais on n'a pas la ressource pour le faire, puisqu'on la dépense au mauvais endroit. Donc je dis, j'aurais tendance à dire à ces gens-là, mais c'est pas grave. Au contraire, capitaliser sur ce genre de choses est montée en valeur la valeur elle est dans le métier elle est pas dans l'infrastructure il faut l'infrastructure mais elle est dans le métier et plus vous serez augmenté pour créer des beaux outils métiers par l'infrastructure plus vous allez créer de la valeur, donc il faut s'élever et c'est intéressant parce que c'est par rapport à l'IA qui arrive il y a une alchimie à trouver entre tout ça, entre les outils l'IH.
Bruno:
L'IA c'est intéressant alors je sais que j'avais dit cette dernière question mais du coup j'en ai une autre qui vient, je vais essayer de la structurer parce que j'ai reçu il y a quelque temps sur ce podcast, le créateur de Webflow, je ne sais pas si tu connais Webflow c'est un outil qui permet de créer des sites web, en no code slash low code il avait eu une phrase, volontairement provoquante mais que je trouve intéressante, il disait en fait, Webflow est plus proche du javascript que le javascript n'est proche de l'assembleur parce qu'en fait il y a tellement de couches d'attraction entre l'assembleur et le javascript qu'en fait un outil qui te permet de créer un site web en low code va être plus proche de ça. C'est vrai qu'on voit quand même une tendance on a des langages qui sont de plus en plus haut niveau, il y a de moins en moins de développeurs qui font du C par exemple d'assembleur j'en parle même pas. Et en fait la question c'est de se dire que tu vois on a essayé de simplifier énormément de choses, est-ce que la nécessité d'avoir un, J'ai du mal à s'envoyer ma question, mais en fait, ce que je veux dire, c'est que, d'une certaine manière, ce que tu fais avec Digital Substrate, c'est que c'est aussi une couche d'abstraction supplémentaire. Ça te permet, du coup, d'ajouter un ensemble de choses à ton logiciel sans que t'aies besoin. Tu vois, si on prend les notions de distorisation, c'est qu'en fait, t'as complètement abstrait ce sujet-là, et du coup, on n'a plus à le gérer, parce que c'est géré nativement. Et ma question, du coup, ce serait dans un certain... Déjà, est-ce que c'est vraiment le cas ? Et puis, est-ce que c'est pas des choses, en fait, qui devraient être portés directement par les OS et que ce n'est pas aussi un manquement des OS de ne pas ouvrir ce genre d'API ou est-ce que ce n'est pas aussi dû à une... Si on reste sur ce sujet d'historisation, est-ce que ce n'est pas un sujet aussi de paresse de nous en tant que développeurs et développeuses de quand on commence un système, on se dit en fait moi je fais mon CRUD et je modifie la data direct et puis si un jour on me demande un undo redo on se posera la question en ce moment là Est-ce que c'est pas aussi un sujet de paresse qui fait qu'on a tendance à aller toujours au plus simple ?
Jean-Christophe:
Intéressant. Alors, il y a plusieurs questions, donc j'essaie de répondre, je crois qu'il y a trois questions. Alors, est-ce que ça devrait être mis dans l'OS ? Oui, ça me semble une question pertinente. Aujourd'hui, ça ne l'est pas. Donc nous, on développe des outils. Si je devais répondre comme ça à chaud, je dirais oui certainement. Faire attention parce que, on définit une sorte de standard pour faire les choses. Et moi, j'aime bien, la pluralité. J'aime bien que je ne veux pas imposer des choses. Je dis, voilà, nous, voilà comment on fait les choses. Après, d'autres peuvent faire autrement. Et je n'aime pas imposer. Donc, ça pourrait être une façon de faire les choses. Et ça pourrait être, effectivement, un data OS. C'est un data OS. Donc, on peut le déployer. Et je pense que ça pourrait faire partie complètement de l'OS à un moment donné. Ça peut... On peut considérer que si on le met ensemble, ça fait un OS. effectivement, et d'ailleurs c'est neutre au niveau des langages, c'est neutre au niveau des OS aussi ça tourne sur tout donc c'est une couche une sorte de couche de middleware d'abstraction de la manière mais par contre, par rapport à la question sur l'abstraction, c'est pas une couche d'abstraction supplémentaire de mon point de vue en tout cas parce que ça remplace quelque chose c'est simplement que cette couche là, elle existe dans tous les systèmes que l'on développe, et on dit, cette là, il faudrait la remplacer. Par quelque chose qui arrive sur étagère et qui a des propriétés souhaitables qu'on recherche tous. Donc, on n'est pas en train de rajouter du code. On est en train de remplacer du code. C'est ça l'idée. Et d'ailleurs, une question qui a été posée par un éditeur, un directeur d'éditeur, quand j'ai expliqué ça il y a un an et demi, j'avais expliqué déjà les premiers principes et il s'était un peu énervé. Il a dit, ah mais moi, j'ai des équipes qui ont tel langage, tel machin, qui ont développé des millions de lignes de code et puis c'est déployé chez mes clients et puis ils ont leur data. Tout ça, c'est un passif énorme. Je ne peux pas jeter tout ça et tout réécrire et vous me demandez de tout casser. Et c'était un gros choc pour moi à ce moment-là. Et je me suis dit, mais il a raison. Surtout dans l'omène industriel, on est enchassé dans des systèmes qui sont extrêmement lourds et résilients quelque part ils sont là on peut pas les détruire ou les réécrire et donc on a pris en charge cette demande là et on a dit notre système doit être capable de supporter ce que j'appelle le legacy c'est à dire que quand vous avez quelque chose qui existe et qui est ce qu'il est il faut être capable de l'enchasser dans ce nouveau système, et ça ça permet de récupérer tout ce qui existe et même de l'augmenter et ça c'est assez magique c'est un effet c'est un effet que je n'avais pas prévu au départ mais quand on fait ça c'est assez incroyable on arrive à augmenter le legacy et à retrouver de la dynamique fonctionnelle sur du legacy qui est enlisé. C'est assez étonnant.
Bruno:
Canon. Top, merci beaucoup Jean-Christophe pour cet épisode.
Jean-Christophe:
Merci Bruno de m'avoir invité.
Bruno:
J'aurais deux dernières questions pour toi avant de conclure cet épisode, les questions rituelles du podcast. La première c'est est-ce qu'il y a un contenu que tu souhaiterais partager avec l'ensemble des auditeuristes ?
Jean-Christophe:
Peut-être plusieurs. J'aime bien, Three Brown, One Blue, je crois que c'est le titre. C'est un youtuber qui aborde des sujets super intéressants au niveau mathématiques et autres si vous avez l'occasion, allez le chercher sur Youtube si vous ne connaissez pas, il est extraordinaire, j'aime bien aussi des Youtubers comme Monsieur Phi, j'adore ou Le Réveilleur, j'adore ce qu'ils font je trouve ça extraordinaire, et Monsieur Phi notamment sur la partie IA qui est brillant je trouve sur son analyse, et ça nous concerne tous, dans le développement, il faut qu'on y travaille et qu'on réfléchisse à ce que ça fait et comment avancer sur ces sujets-là. Voilà. Je vais citer aussi peut-être Nada Nakita, qui est une chercheuse avec qui j'échange en ce moment, qui s'intéresse beaucoup. Elle fait partie du labo qui s'appelle le LEMNA, Laboratoire d'économie de management de Nantes, Atlantique, je crois. Et on discute pas mal sur la dette informatique. C'est son sujet de recherche. Et je trouve qu'elle est très intéressante dans ce qu'elle dit donc n'hésitez pas à aller la rencontrer si vous avez l'occasion, c'est intéressant.
Bruno:
Canon, merci beaucoup. Et dernière question, la plus importante de ce podcast, est-ce que tu es plutôt espace ou tabulation ?
Jean-Christophe:
Alors, mon Dieu, en fait, je dirais que là aussi, je suis très neutre par rapport à cette demande-là. Je dirais que je laisse l'autocomplétion faire le travail. Et puis maintenant, plus lié à le code, ça devient de moins en moins important. J'aurais tendance à dire que le tab a un petit intérêt par rapport aux espaces. C'est qu'il permet dans l'éditeur de régler la largeur de l'indentation du code. Et il y a quelques utilités quand on fait il y en a qui s'amusent à élargir démesurément la largeur du table pour dire voilà si ça s'éclate sur la droite votre code c'est pas bon.
Bruno:
Signe Merci beaucoup Jean-Christophe.
Jean-Christophe:
C'est moi qui te remercie.
Bruno:
Merci à tous d'avoir suivi cet épisode je vous invite bien évidemment à aller checker tout ce que fait Digita Substrate parce que c'est effectivement hyper intéressant. Et cette logique du undo redo je pense que vous voyez tous un peu toute la complexité que ça peut amener avec elle pour cette simple demande, donc n'hésitez pas à aller checker du Quack Digital Subprès si vous voulez vous faciliter la vie sur tous ces éléments-là. N'hésitez pas aussi à aller faire un tour sur le Tipeee du podcast si jamais vous voulez contribuer à ce podcast et lui permettre de continuer à progresser, à évoluer et même tout juste parfois à exister. Et c'est aussi un bon moyen pour choper des goodies. Je vous remercie beaucoup de partager ce podcast autour de vous, je vous souhaite une très bonne fin de semaine, je vous dis à la semaine prochaine et d'ici là, codez bien !
