Bonjour et bienvenue dans ce nouvel épisode de messages à caractère informatique, épisode
numéro 100 sans candé.
Nous sommes toujours les 9 yambiers de 1026, je suis Horace Ronzales et avec moi je
suis de Yame Herbeilleux tel que Yannick, Tiela.
Bonjour à tous.
Bonjour.
Qui se casse derrière c'est Chacquialer par 3 comptes, normal c'est un Chazoukiper.
A Cépanda.
Et derrière le canard en plastique, on a notre ambité de Jure, François Fouquet.
Bonjour François.
Bonjour.
Je ne vais pas griller.
Vous étiez déjà le premier, mais on va quand même faire un tour de table rapide.
Cette fois on commence à l'inverse.
François, qui est-il ? Qu'est-ce que tu fais à conteneur ?
Alors je suis le sitio et un des confondateurs de DataFings, un startup qui fait des digital
twins, donc on fait des jumeaux numériques pour les infrastructures, pour les mépaqueux
d'ailleurs, et puis on a développé des technologies de base de données, de programmation, de base
graph, de time series pour résoudre nos problèmes.
Donc on est ravi de parler de ces sujets-là, de gros volumes de données, de systèmes de
résoudement.
On est un petit peu à la croise et des chemins entre l'IA, la simulation scientifique et
une build data.
Et si vous n'avez pas écouté l'épisode précédente, je vous le recommande quand François
commence à parler de use case et comme ça, amené à créer de la technologie, de la
vraie technologie, je pense que vous seriez ravi d'écouter l'épisode précédent.
Bon, on continue les tours des tables et panda, qui tiens ?
Moi je travaille chez Clever Cloud sur la partie compute, principalement, donc tout ce
qui est...
Quelqu'un veut développer quelque chose chez nous, ça va où ?
Et entre autres, et puis tous les produits affidés à ça, donc Kubernetes.
Et Yannick ?
Je travaille également à Clever Cloud.
Je suis développeur AR&D et développeur sur notre solution matérielle de base de données
serverless que l'on utilise pour créer nos nouveaux produits dont justement le Kubernetes,
qui est en charge de panda.
Parfait.
Je suis très prêt par le Kubernetes.
Les covoisettes, je vais faire un peu de...
Je vais faire des tours des produits.
Donc panda est piloté par Inappia et server.
Bon, qu'est ce que...
On a plein de choses à vous parler aujourd'hui, mais on me reproche souvent
entre guillemets que les Macie ne peuvent pas se péché d'avoir intornure politique.
Effectivement, l'épisode précédent n'en a pas parlé, mais cet épisode y peut.
Je pense que la première news, j'ai été l'esçonneur pendant de quoi tu voulais nous parler.
Alors, la Commission Européenne a annoncé récemment faire un call for evidence sur l'Open Source.
L'idée, c'est de dire quelle solution existe, que ce soit Open Source ou autre,
mais qui permette de gagner en autonomie sur les composants clés qu'ils utilisent.
Ça fait un peu très légèrement écho à l'actualité,
puisqu'il n'a pas fallu longtemps depuis début 2026,
pour qu'un certain nombre de choses se passent dans le monde,
surtout si vous avez du pétrole chez vous,
et qu'on remette un peu en question votre souveraineté.
Donc ça pose une réflexion de fond qui s'est embrayée il y a quelques mois,
années, je dirais, de manière assez sérieuse, un peu partout en Europe,
qui est de dire, c'est quoi les éléments critiques pour que nos pays fonctionnent bien,
et comment on peut faire en sorte que même si on se fâche avec des alliés historiques ou des fournisseurs,
on arrive à fonctionner bien.
C'est un sujet qui m'intéresse depuis très longtemps,
et il y a peut-être 10 ans on est un peu pris pour des fous furieux,
voir des compétitions,
il n'y a pas d'Isan, il est aussi peu que 3San, même 2,
à chaque fois qu'on parlait, on est très très tê,
j'ai un demandé hippie, ou de pessimiste.
Et puis on a vu un certain nombre de signaux d'alarme un peu inquiétants.
Par exemple, les contributeurs open source iraniens qui sont fait couper leurs accès,
dans le bloc de sanctions contre l'Iran,
d'accord il y a un bloc de sanctions, il l'applique, c'est le jeu des États,
enfin le mec était quand même en train de contribuer sur un truc qui sert à l'humanité,
je ne sais pas si c'est intéressant de le couper,
et plus récemment, je crois que c'est les juges de la CPI qui se sont fait sortir de l'intégralité des produits américains,
ça inclut les produits numériques,
ça inclut tous les produits numériques,
y compris les systèmes de Payman, carte bancaire,
et tous les restes, c'est pas seulement les mails, les drives.
C'est à dire que à un moment, même si c'est désagréable ne plus avoir Netflix,
et ne plus avoir jamais les mails, on pourra peut-être s'en passer,
être sorti de Swiss et Visa,
c'est quand même une expérience très désagréable au quotidien.
Surtout que si le société a rien physique,
il deviendrait difficile à servir au quotidien pour tout Facilman.
Et l'idée que porte un peu cette démarche,
je pense, est intéressante de la Commission Européenne,
l'idée, c'est pas de dire,
je pense qu'il faut que l'intégralité de la technologie et de l'industrie soit gérée par chaque pays,
parce que du coup on refraie d'y faire les mêmes choses,
et parce que l'un dans l'autre, le multilatéralisme,
a l'intérêt de stabiliser les relations entre les États.
Si je suis dépendant de toi et que tu es dépendant de moi,
on a moins intérêt à se mettre sur la gueule.
Donc en fait, c'est pas ça le message.
Le message c'est de dire qu'il faut qu'on arrive à déjà
à ce que nos intérêts soient gérés en partie par des choses qu'on maîtrise pour être en sécurité,
et aussi qu'on ait une balance, que ce soit commerciale ou en tout cas de dépendance,
qui soit cohérente avec le résumé.
Ça fait partie des choses qu'on pousse, notamment chez Clever,
avec les produits qu'on fournit et avec ce qu'on essaie de faire.
Il y a un écosystème qui se consolide en France, en Europe, là-dessus,
je pense à OVH, je pense à Scaleway,
il y a plein de...
On attaque la couche fondamentale du cloud et de l'infra de ce niveau-là
pour être capable de proposer quelque chose.
Et je pense que ça résonne un peu avec ce que tu fais.
François aussi dans une dimension édificante.
Oui, complètement. Là où ça fait écho,
c'est qu'il y a une question de souveraineté et de maîtrise un peu de certaines briques technologiques.
Donc nous, on est plus sur la brique tout en bas qui va être composée
par des systèmes qui après sont déployés sur des clouds d'idéalement souverain.
Et donc, oui, on se retrouve à la fois en compétition avec des grands acteurs,
mais à la fois beaucoup plus proches de nos clients et partenaires locaux.
Et donc on essaie de rappeler un peu à tout le monde que la notion de risque
n'est pas qu'une question de taille ou de stabilité ou d'adoption,
mais aussi une question de capacité à bouger, à discuter,
à faire vivre les solutions.
Et donc là, c'est extrêmement bien si l'Europe ne met pas que,
comment ça va réfléchir un petit peu, quels sont les acteurs qui peuvent contribuer
et comment est-ce qu'on peut dynamiser un écosystème pour éviter de simplement prendre la solution
la plus adoptée et basta.
Et parce que c'est la chose la plus simple.
Donc, oui, nous, on a aussi un peu ce discours-là de dire aux gens, réfléchissez à ça,
parce que ça va être important et puis d'autant plus quand on a des systèmes critiques en cible,
là, la situation se pose instantanément.
Je me dis à parler de la notion de risque, parce que ces dernières mois avec des copains
dans d'autres clubs provéidaires et d'autres boîtes européennes,
on blague un peu en disant, et en trompe,
est devenu notre meilleur commercial, parce que maintenant les gens commencent à se rendre compte
que avoir tout dans de Claude Américain ne se peut peut-être pas à la bonne idée qu'il pensait.
Et donc il y a un risque.
Mais j'ai l'impression que entre ces prix de conscience et à y commencer à changer certain produit
et voir comment il peut faire de façon différente,
cette deuxième étape n'est pas encore enclenchée ou ça va plus doucement
que ce qu'on pourrait imaginer.
Je ne sais pas si c'est un expérience semblable ou pas.
Oui, tout à fait.
Nous, nous, nous, on a la même chose.
On discute beaucoup de ça.
On discute beaucoup des technologies avec nos partenaires, nos clients,
de savoir qu'est-ce qui, finalement, de compter un peu dans le landscape de ce qui est déployé,
qu'est-ce qui est risqué ou pas risqué pour eux.
Mais ça bouge doucement.
Ça bouge doucement.
On identifie, on en parle, on regarde les briques technologiques.
Mais néanmoins, pour l'instant, il y a un peu un statu quo qui est difficile à bouger.
On a souvent plus peur du changement que, finalement, du risque réel.
Donc on le voit avec avec pas mal de choix technologiques.
On essaie de le chiffrer, d'expliquer.
Mais ça reste un travail de bon galène pour être franc.
Ou tous les jours, on nous demande de nous justifier pourquoi on n'est pas comparable
à tel ou tel très grand acteur.
Alors que, finalement, ce très grand acteur, potentiellement, ne coche pas les cases,
soit de souveraineté, soit de sécurité.
Donc on est un peu embêté souvent parce que les gens en parlent au café.
Finalement, dans les actions réelles, c'est pas encore.
Ça ne fait pas partie de la grille d'évaluation des choix softwares pour être franc.
Je ne sais pas de notre client.
Donc c'est super si les commissions européennes commencent à en parler réellement,
que ça fasse vraiment parler d'une notation pour le choix des technos.
Parce que, évidemment, nous, on sera contents d'essayer de jouer cette carte-là.
Mais je pense que pour tout le monde, ce serait bien pour un sage un peu.
Qu'est-ce qu'on a ? Qu'est-ce qu'on n'a pas ?
En fait, moi, je pense qu'il y a aussi un élément intéressant qui est qu'on l'entend
régulièrement de la part de détracteurs à nous, qui est, en fait,
la souveraineté, ce n'est pas un critère qui est pertinent au regard des fonctionnalités.
Et il y a un peu un problème de poulet d'oeufs, je trouve, dans cet argument.
Parce que la réalité, c'est que, et je pense que ça vient aussi du fait que le monde du numérique
et que de l'hébergement, de l'analyse de domaine, etc.
est peu connu du grand public.
Mais le fond de ce que j'essaie de dire, c'est que, comme c'est peu connu,
on a du mal à être considéré comme une filière industrielle.
J'en veux pour preuve.
Je pense qu'à chaque fois qu'il y a un changement de gouvernement,
notre chère ami et patron canton débarque sur, je ne sais plus quel canal public,
puis dit, quant à ce qu'on a un ministre de plein exercice du numérique.
Parce qu'en fait, on en appart et toutes les autres filières industrielles, on n'en ont.
Et la réalité, c'est que, à la fois, leur représentation, les budgets allués,
la commande publique et la commande des grands comptes aux États-Unis dans le cloud,
c'est quelque chose d'acté depuis très longtemps.
Et ça explique le déploiement qu'ils ont eu et leur capacité à créer de la fonctionnalité
à outrance, y compris pour introduire du vendor locking.
Mais le point est si on veut, enfin,
c'est nécessaire, utile et ça nous sert qui est cette prise de conscience.
On n'arrivera pas au niveau de fonctionnalité des WS demain.
Donc la réalité, c'est que sur cette prise de conscience,
il faut qu'on acte le fait qu'il faut y aller, il faut utiliser ces solutions-là.
Comme on dit, en France, on n'a pas de pétrole, mais on a des idées.
Du coup, on est motivé pour trouver des solutions,
pas forcément avoir systématiquement la même approche,
mais faire des choses adaptées et avoir cette flexibilité
qui permet de répondre aux besoins des gens.
Mais il faut construire la filière, il faut la consolider, il faut la développer.
Je m'en dis, on reste petit en termes de notre capacité à produire.
Et ça vient des choix qui ont été faits ces dix dernières années.
Là où je te revois complètement, c'est sur le point
on n'a pas forcément tout le spectre de fonctionnalité,
mais la question sous-jacente, c'est est-ce que vraiment, c'est ça dont on avait besoin ?
Parce qu'on a un peu une sorte de monotypie, en particulier dans le monde du logiciel
sur lequel je peux donner un peu mon avis sur ce que j'ai vu dans le panorama des techno.
On a souvent tendance à dire, dis-moi la bonne solution pour si ou pour ça,
ou la meilleure DB, et en fait la bonne réponse en toute honnêteté,
ce serait pas la meilleure, il y a plein de choses qui vont devoir être choisies
et tester suivant les bons use case.
Et donc je trouve que la capacité à adapter quelque chose de bien précis
pour n'avoir que ce dont on a besoin,
ce serait bien plus important que d'avoir tout un tas de choses dont on n'a pas besoin.
Donc si on repart sur les grands acteurs,
il nous force quelque part à rentrer dans un moule
qui par moments ne me sent pas toujours adapté à certains de nos...
En tout cas nous, de notre point de vue, à certains de nos déploiements, nos besoins,
et donc voilà, on aimerait bien à la fois ce standard niveau
pour que les gens puissent pas tout refaire à chaque fois,
ça c'est la première des choses,
et on l'a dit plus on sera ensemble à ramets de la même direction, mais au moins ce sera.
Mais par ailleurs, à se garder quand même la possibilité de se dire,
peut-être suivant nos usages, nos acteurs locaux, etc., on fait les choses bien.
Je pense que j'ai une bonne illustration de ce que tu dis sur la partie des fonctionnalités.
Il y a quand même un standard de factures qui a été amené par Google
sur c'est quoi le niveau de qualité dans ça, cette coordination qu'il faut,
et ça a vachement impacté la structuration des logiciels,
notamment sur la partie coordination, etc.
Dans l'idée, il y a une époque où notamment la sortie de Google Docs,
Google a state que le standard de qualité par défaut,
c'est un SAS geo répliqué qui ne tombe jamais,
qui est synchronisé en permanence,
et pour être très francs, ils ont un peu été comme des bois,
c'est-à-dire que pour active ce niveau de coordination, etc.,
les mecs ont quand même mis des orloges atomiques toutes les 3B,
parce que du coup tu as moins de problèmes pour faire passer tes transactions,
parce que tu es forcément à l'heure.
La réalité, c'est que tout le monde n'a pas besoin de ce niveau de coordination,
geo réplication, etc.
Oui on a besoin de backup, oui on a besoin de choses,
mais le fond du problème c'est que pour faire un SAS de documents,
tu as juste besoin de CRDT et d'un peu de réplication.
Tu n'as pas besoin d'un système qui est full online tout le temps
synchronisé bidirectionnel et conflict free.
Je...
Désolé, mon blog statique, il faut qu'il soit geo répliqué.
C'est ça.
Et qu'est-ce que tu as déployé ce Kubernetes ?
Bien sûr.
La Kubernetes c'est une des illustrations de la justification de Kubernetes
passe par ce standard là,
c'est comme ça qu'on doit fonctionner.
Et sauf que la réalité, je ne sais pas si y en a déjà certains d'entre vous
qui ont essayé d'utiliser par exemple la fonctionnalité de fédération du cube.
C'est un enfer.
En gros, c'est de l'élection master worker très simple,
le cluster fonctionne en master,
enfin master worker avec les noms, etc.
Et les clusters entre celles et puis y a un chef.
Donc en fait c'est l'actif passif.
On n'a globalement rien inventé.
Probablement Google fait mieux avec ces technologie internes
mais en tout cas l'application open source n'est pas transcendante
et ça ne résout pas vraiment les problèmes.

Donc je suis d'accord, je charge moins sur ce côté de...
On n'est pas obligé de faire pareil, en fait on peut faire mieux différemment.
Oui et puis par moments, comme tu disais,
il y a eu des couches qui ont été faites pour de très bonnes raisons
avec ces couches aussi qui ont été faites.
Par moments elles sont réutilisées et réassemblées
avec tout le legacy de ces choix-là qui remontent.
Et tant en tant on tombe sur des architectures Frankenstein,
ou bon voilà pour citer personne,
mais on tombe sur ce genre d'archies où on se dit
vous avez accumulé tous ces choix-là
pour de temps en temps remonter quelques données par seconde
et on n'est pas très loin du hall of war for le coup de calcul.
Et finalement, ça a coûté très très cher pour quelque chose
qui aurait pu, par rapport au besoin de métier,
être beaucoup beaucoup plus simple.
Donc il y a une espèce de dette technique des choix
qui sont devenus strict au standard
où tout le monde se dit il faut d'abord ça pour être sûr de tout faire
mais ce qui ne comprenne pas c'est que pour faire ça,
il y a un coût d'entrée et un coût de maintenance qui est quand même élevé.
Et ça c'est un peu dommage parce que c'est ça qui après nous bloque
dans certains choix par moments nous dit
ben finalement j'ai besoin de ça, du coup je suis bloqué chez tel provider
parce que c'est les seuls à offrir ça pour penser tellement toujours.
C'est un projoué.
Ça c'est un projoué.
On leur a dit mais c'est dommage parce que en fait vous n'aviez pas vraiment besoin de ça.
Donc en fait vous n'étiez pas vraiment bloqué
et juste tant que vous ne remettez pas ça en cause,
vous êtes effectivement bloqué.
Donc ça fait partie du processus,
finalement d'expliquer aux gens ce qu'ils utilisent vraiment.
Est-ce que vraiment ils avaient besoin de ce blog répliqué avec 99,999
ou est-ce que vraiment bon...
Si on répliquait sous toutes les régions de monde
quand 99% de tes clients sont en Europe
et tout...
C'est ça.
Il faut qu'il soit répliqué, il faut qu'il soit accessible
avec une préférence locale
et en plus il faut de l'écriture concurrent sur le blog.
Ça souvent c'est le bingo.
C'est une vraie question.
Et puis ça va tout le temps du cloud provider
jusqu'au choix du réseau, jusqu'à la DB
et nous on est dans ce dernier cas où on se fait souvent élevé.
Mais ça va plus loin, ça va même
d'une façon comme les développeurs développent
et que ça soit front-back
parce qu'on veut dire mais les fronts, oui les fronts
les sutillas sont devenus de plus en plus complexes
au point que parce que il y a d'autres cours
et l'année dernière,
il recommençait à donner des cours de programmation web.
À cette année, c'est déjà inscrit à mon époque.
Mais aujourd'hui, tu commences à expliquer aux étudiants
que les sutillas ne sont pas là pour faire un petit
élo-word en application web.
Et tous ceux qui sont là pour comprendre,
ils vont dire non mais si je ne m'explique pas à l'époque,
je ne vais pas démarrer quoi.
Tu aurais fait du pearl.
En fait, il y a longtemps, je me suis dit que c'est très lointain,
il y avait un format structuré qui s'appelait HTML.
Et puis depuis on a fait des choses.
Donc on a commencé par essayer de faire du templateting
et puis finalement on s'est dit qu'on allait représenter l'arbre
de ce truc là de manière virtuelle pour en faire.
Non mais plus voilà, tu commences à jouer avec des vandelles,
des systèmes de construction, des services de rétéling,
des ddds, et simplement en expliquant les concepts,
bah, je perdus une journée mais les étudiants sont
je vais retourner faire des bacs à l'air plus simple.
La première fois que j'entends ça.
Non mais c'est vrai que par moment et quand on voit certains résultats,
on se dit mais il y a 12 stack technologiques,
il y a des problèmes de VDOM et des problèmes de rendering, etc.
sans parler du problème du bundler qui a explosé en plein vol et fait pététricien.
Et on regarde la page, on dit les gars il y avait 3 films et un bouton.
Donc je vais les parler.
Ça pourrait être la bobille HTML avec un petit pain de CSS,
tout au plus.
Je me rappelle quand j'ai commencé à faire du front,
et que j'ai mis le devoir dans l'engrenage de webpack,
et qu'il fallait rajouter les pliens 1 à 1,
et que tu te retrouvais à avoir ton paquet de JSON qui faisait 50 lignes,
où tu avais juste la définition de ce que ça devait faire.
Donc là tu étais content, et puis après tu avais le webcast config à mettre à jour.
Le machin il faisait...
Je vais aller faire autre chose de ma vie.
Je me suis juste venu faire un site.
L'intérieur c'est goût par la complexité, quelque part,
et poussé par des exemples, comme c'est qu'on a parlé de Google,
moi on ne met pas ma culcée de tester Covernaites.
J'ai kiffé Covernaites, j'ai fait beaucoup.
Par contre, me dire qu'il faut Covernaites pour déployer un petit appli Java
ou ton blog statique Yannick,
bah...
Non, je suis plein d'arguments,
il y a eu quelques postes de Covernaites,
c'est le standard de base, donc c'est pour ça que j'ai fait un petit truc.
C'est bien de déployer son Covernaites, consacrer une forme,
peut-être une habession d'être une forme,
et si on a réutilisé notre mart-au-rousse pour essayer de viser des vies,
on se porterait mieux, on prenne un petit tournevis, ça passe en général.
Bah, regardez, déployez vos blogs sur Cleveur,
on a des supers applications statiques.
Un des trucs qu'on défend depuis longtemps,
c'est quand tu regardes l'histoire de Cleveur,
cette boîte, c'est qu'on souhaite un pas en parallèle de l'histoire de Covernaites,
et qui est une approche assez différente,
et beaucoup de gens nous disent oui, mais en fait c'est plus compliqué de packageer pour Cleveur,
et en fait c'est faux, c'est juste que les gens ont plus l'habitude.
Mais la réalité, c'est que nous, notre API, c'est Git,
et on build avec les systèmes des langages traditionnels.
Donc en fait, à la fin, il faut voir Cleveur comme un gros rappeur de Linux standard.
C'est très bien, c'est cool à utiliser, mais c'est un rappeur de ton truc,
à la fin, ça sera packageer correctement, et il va sur une machine Linux,
et ça sera très bien.
Et des fois, on a des discussions compliquées avec des éditeurs,
où les mecs nous disent oui, mais je peux pas mettre ma new chart,
En fait, Elm est devenu le standard de packaging de tout,
et tu as vu le nombre de couches que t'avines entre ton logiciel et ton déploiement.
Alors oui, tu utilises la paye cube qui est standard, mais à part ça,
enfin Elm, on peut quand même en parler de ce nombre de Elm,
Elm, c'est un moteur de templateing pour générer du Yamel,
qui est une abstraction standard de facto, de comment est-ce qu'on crée de l'infra?
Il y a quand même un moment où il y a un problème.
Là où tu as donné le bon mot, c'est le de facto.
C'est surtout ce qu'on voit là maintenant, c'est que,
nous on a un peu, évidemment le problème,
on propose quelque chose un peu incontrecurrent, un peu exotique, quelque part comme Techno,
et souvent on a le même problème que vous, à se dire,
bon là j'ai quelque chose de nouveau à apprendre,
donc même s'il n'y a qu'une ligne de code à apprendre,
ah ça fait déjà trop une ligne,
si vous comparez à ce que vous êtes prêt à accepter sur quelque chose
pour lequel vous êtes dans la certitude de faire le bien,
puisque c'est le standard, c'est pas facile quand même.
Donc on a cette friction un petit peu de, voilà,
les gens acceptent de faire quelque chose parce qu'on leur a dit que c'était bien,
et il y a un petit peu ce côté washing de dire,
c'est bien, c'est bien, c'est bien, donc t'inquiète pas, fait comme ça,
et dès qu'après on fait quelque chose, même potentiellement plus simple,
pas toujours, des fois effectivement c'est compliqué,
parce que c'est pas aussi mainstream et pas aussi outiller,
mais des fois c'est pas vrai, des fois c'est même l'inverse,
mais là, acceptabilité elle est quand même compliquée,
parce qu'on sort un peu de sentiers bas dessus.
Et c'est là où je disais, c'est un peu frustrant,
parce que quand même quand on a la vision un peu de ce que ça va coûter à long terme,
tu parlais de Helm, tu parlais des déploiements,
tu te dis oui tu suis le sentier classique,
oui Google te répond assez vite sur la première réponse comment faire ça,
mais le chemin que tu prends jusqu'au déploiement,
tu vas payer pas mal de transpiration,
en particulier si un jour tu as un problème,
et où le framework qui abandonnait,
ce qui va bien sûr arriver d'ici quelques temps peut-être.
Après il y a un autre facteur.
Il y a une certaine chose, c'est du write only,
tu l'écris une fois et tu n'y retouches plus jamais,
parce que c'est même pas ce que tu as écrit,
tu vas chercher des trucs qui sont sur un GitHub,
qui te font des trucs, machin, une fois que ça marche,
tu ne touches plus.
Mais il y a un autre facteur,
et il commence à être assez vieux pour avoir connu
un début de l'informatique,
il y a fait ça dans l'informatique bancaire,
et à l'époque on disait,
personne ne jamais te licencie pour avoir chose si,
quel que ça n'est plus tard,
c'était personne ne jamais te licencie pour avoir chose si,
et maintenant ça devienne,
personne ne jamais te licencie pour avoir chose si,
AWS ou Kubernetes,
et donc il y a aussi un facteur
de moi, en tant que manager qui fait certain choix,
c'est beaucoup plus ressurgant de me rabattre,
et c'est pour ça que je vais aller,
pour les cloud providers américains au catalogue,
à trois ans les mains,
qui sont ensemble des petits providers européens
et des éditeurs,
qui vont faire les mêmes choses moins cher,
mais si ça ne passe pas,
s'il y a un problème,
c'est mon poste qui a risqué.
Et ce facteur là, il est extrêmement lourd.
C'est honnêtement le plus gros facteur bloquant
pour des petits éditeurs comme nous,
et nous on n'arrête pas de clamer,
de leur dire,
laisser nous une chance,
ensuite évaluer nous sur les performances,
il n'y a aucun problème à ce que vous nous dites,
vous n'êtes pas assez rapide,
pas assez facile d'accès, etc.
ou ça me prend trop de temps de former mes développeurs,
soit c'est quelque chose que je pourrais entendre,
mais bien souvent,
ce n'est pas ça le discours qu'on a,
c'est plutôt,
non on ne va pas faire le choix de tester,
c'est potentiellement pour moi personnellement trop risqué,
et donc en général,
même ce qui nous arrive,
et ce qui est assez triste,
c'est qu'ils vont faire le choix d'un grand acteur
pour lequel on leur dit,
en tant qu'architecte,
pas en tant que voilà éditeur de logiciel,
on vous dit que là ça va piquer très fort,
ils le font quand même,
ça plante,
et après ils reviennent en disant,
qu'est-ce qu'on fait ?
Bon, c'est pas très confortable comme situation,
on arrive sur un projet qui s'est mal passé,
il faudra se rattraper aux branches,
faisons pas ça,
et on a du mal à short cut un peu cette phase-là,
c'est bien dommage,
parce que ça fait perdre du temps,
de l'argent,
et voilà, on parlait tout à l'heure des réseaux numériques,
enfin des jumeaux numériques,
nous ça nous a tristes un peu,
parce qu'on perd du temps
sur des choses qui pourraient directement
impacter certains citoyens,
c'est bien dommage qu'on perde du temps là-dessus,
donc essayons de gagner du temps,
de construire le warnez de ça,
d'y dire aux gens,
au moins essayez,
donnez-nous une semaine peut-être deux,
on fait un poc,
donnez-nous le poc,
on vous montre ça,
et ensuite on évalue, mais...
Et donnez-nous les feedbacks,
c'est très courrier parce que c'est même phrase-là
quand on utilise dans plein de cette langue,
donnez-nous une chance,
et si ça marche pas,
dis-nous que ça marche pas,
on le corrigera,
mais simplement,
n'édite pas d'avance,
ne se risquez,
vous avez allé sur la solution connue.
Et typiquement un des arguments
qu'on nous oppose souvent,
nous sur...
En fait, on est souvent comparés
avec Kubernetes en tant que plateforme,
que les voilà pas, donc, passent,
et on nous dit oui, mais en fait,
on peut faire la même chose avec Kubernetes,
tu mets 2, 3, le UCL Open Source,
tu mets du Hargo CD,
tu mets un GitLab dedans,
et à la fin, ça marche,
ça se fait,
ça pose d'autres questions.
La beauté des ingénieurs
qui boit sur la plateforme chez nous,
il y a une raison,
c'est pas par hasard,
c'est-à-dire que ça demande beaucoup
d'enquête quand même pour avoir
un système qui marche bien
et le UCL qu'il faut gérer,
mais pour être clair,
je...
Enfin, je...
J'utilise Kubernetes
et j'en d'aupère depuis facilement 6 ans.
Donc en fait, ce que je pointe du doigt,
c'est pas que c'est pas une bonne solution,
c'est...
Il y a quelques choix qui me paraissent
un peu étranges sur la conception
et surtout sur l'interface
d'utilisation du truc.
Faire une appellée d'infrastructure standard,
c'est pas facile,
à un moment,
on peut rendre des trucs génériques
pour mesurer ce que ça trouve, etc.
Mais les choix de...
Bah, les déploiements,
les pods, les services,
vous rentrez dans énormément de...
de contexte
et de connaissances
dans un outil
pour arriver à être capable
de l'utiliser
et je trouve que c'est un peu
une opportunité ratée
dans certains côtés
de faire un truc un peu plus justi
à quoi ?
Ouais, c'est ce coup caché
que les gens...
Voilà, on parlait beaucoup d'open source,
aussi de capacités de maîtrise.
On le rappelle beaucoup.
C'est pas parce qu'on a accès
à un logiciel qu'on en a la maîtrise.
Ça demande de l'investissement des gens,
finalement, des gens qui vont y passer du temps.
Et cette chose-là
elle est pas mal oubliée.
Je sais pas mal d'acteurs.
Donc nous aussi,
on utilisait beaucoup de logiciel open source.
On en fournit aussi en open source
et on sait le coup que ça a
pour des deux côtés à maintenir.
C'est dommage.
Je sais pas, pris en compte
alors que pour le coup,
là, c'est là où on pourrait reconstruire
un réseau d'acteurs locaux
qui marcheraient très bien
et qui seraient auto-alimentés par ça.
Donc...
On pourrait imaginer
pousser des standards aussi.
Et on pourrait imaginer
pousser des standards.
Des standards qui viendraient plus, d'ailleurs,
des usages
que de temps en temps, on va dire,
des organismes de standardisation.
On a beaucoup, par exemple,
de standards de données
qui nous sont poussés
pour alimenter les jumeaux numériques qu'on fait,
qui sont le plus part du temps
pour être transparent,
pas complètement alignés
ou qu'ont été complètement contournés.
Si je suis complètement honnête avec vous,
dans le grecate,
on a admis dès le départ
qu'on n'aurait aucun importeur standard.
Je vous dis à être honnête,
ça n'est jamais arrivé.
Ça n'est jamais arrivé
que les données arrivent propres
et que ce soit importé propre, etc.
Ce n'est pas dire que le standard était mauvais,
mais simplement, il n'a pas vécu.
Les gens n'avaient besoin,
ils n'ont pas pu discuter.
Le champ extra,
il y avait un gros champ string qui passait,
il y avait un gros gisonne
qui est tombé dedans,
et c'est parti comme ça.
Des cas d'exception, on en a plein.
Ce n'est pas forcément dramatique,
ce n'est pas ça qui nous bloque,
mais ce n'est pas facile.
Quand on discute avec les acteurs,
nous, comme on voit les importes données,
on leur dit que vous n'êtes pas loin
d'être presque tout saliné.
Souvent, les standards ne sont pas si loin.
Vous discutez, mettez-vous d'accord,
et vous allez voir, vous n'êtes pas loin.
Ça pourrait très bien marcher ensemble.
Il y a un peu, je pense, le piège
qu'on a dans la IT,
c'est-à-dire que c'est très iteratif
et qu'on peut se permettre beaucoup de choses.
Des fois, on s'en permet trop.
On peut parler deux secondes des mark-up language.
C'est ingérable.
Un des trucs les plus utilisés aujourd'hui,
c'est Yamel.
Le nom de Yamel, c'est Yet another mark-up language.
C'est-à-dire que les mecs, ils étaient déjà conscients
qu'ils partaient faire autre chose.
Quand on voit le nom qui existe depuis,
il y a Toml,
il y a Cube qui a fait sa sous-variante de Yamel.
En disant oui, mais en fait, c'est quand même chiant
à utiliser parce qu'il n'y a pas les bons délimiteurs.
Donc en fait, on va rajouter des trucs.
Donc, moi, je suis chiant.
Mais, enfin, dans l'industrie,
on arrive à ancrer des standards
qui sont pertinents, qui fonctionnent.
Y a un standard, Y a Y-Samel.
Personne ne veut en faire.
Oui, et puis il est large aussi Y-Samel, c'est un peu le point.
Mais on arrive à se dire qu'à peu près
que la bonne façon de brancher
de l'électro-portatif, c'est USB-C.
Et on arrive à s'y tenir à peu près.
Alors les Chinois, ils ont fait objection
de votre honneur, nous allons faire notre propre standard.
Il sera compatible USB-C.
Mais du coup, le point est,
on devrait pouvoir réussir à se dire, bon,
on peut peut-être avoir que 3 mark-up langues
qui sont à peu près interopèrent,
parce que dès que tu fais un outil, c'est un genre...
Enfin, je vois ce que tu veux dire en tant qu'éditeur,
il y a plein de choses comme ça qui sont à faire d'alors.
Ah ben, bien, les formats de données,
c'est le faroeste, c'est vraiment le faroeste.
Après, alors, il y a le mark-up langues,
c'est comme ce que tu disais,
puis après, il y a ce qu'il y a dedans,
avec les champs, les problèmes de l'unité,
même au sein des mêmes fichiers.
Tant en tant, on a des formats avec les nouveaux coups qui changent,
et on nous dit, mais ça a été une migration de système.
Voilà, donc l'unité a changé, vous inquiétez pas,
ça partit à de la ligne 101212.
Donc, tu n'as pas de système qui tourne en même temps
avec des jolies différentes.
Oui, bien sûr. Donc c'est vrai que c'est un peu dommage,
parce que c'est les choses pour lesquelles,
quand j'ai eu mes premiers cours de software engineering,
et que j'ai aussi propagé en tant que professeur de software engineering,
en disant, mais attendez,
on ne propage pas une valeur sans unité.
Je vais être transparent, côté boîte,
j'ai un CSV avec un gros aideur,
une valeur en dur à l'importeur, parce que j'ai pas de choix,
et puis l'unité, elle n'est pas dedans,
et change à la ligne 101212, parce que c'est comme ça.
Et donc, ça, c'est un peu dommage,
parce qu'on prend des risques pour des softwares,
on connaît les problèmes que ça a été,
on a tous entendu les histoires de fusée arienne
qui avaient pété en plein vol au tout départ
sur des problèmes comme ça.
Et finalement, on change de tech,
on change de techno, on a mis 12 000 frémi-workwebs,
mais le vrai problème de fond,
c'est vrai que par moment on se dit, on l'adresse pas trop.
Alors, ce serait un petit moment là pour...
Oui, quelques formats d'un port comme ça,
qui soit un peu plus stabilisé,
parce que ça, ça fait perdre du temps à tout le monde.
Donc, oui, il y a des choses qui évoluent et d'autres partiellement.
On retombe un peu sur nos pattes,
sur en fait, on a besoin de se structurer en tant qu'industrie.
Oui, c'est ça.
C'est une certitude et de réfléchir aux acteurs
qui peuvent y participer, je pense que voilà.
Il faut qu'on réfléchisse à ce cercle-là,
ce cercle vertueux, et qu'on le mette à place.
J'espère que les évaluations pour lesquelles la discussion
a commencé tout au départ vont prendre à ça en compte,
parce que ça me semble essentiel,
sinon, pointer du doigt servira à rien.
Après, qui t'en est pas à me faire des amis,
je pointe sur le fait qu'il faut se structurer dans l'industrie,
quand toute une partie de notre industrie
se révendique, on n'est pas une industrie,
on est des artisans, on est des craftsmen, craft people.
Et donc, je vous remercie que même sur ça,
on n'a peut-être pas collectifment la volonté
d'être une industrie, il y a beaucoup, beaucoup de fierté,
justement dans ce nom et moi, je fais mes choix individuels
et je vais faire une belle architecture,
combien de fois on a entendu la idée de une belle architecture,
plutôt qu'une architecture efficace, standardisée, antéopérable.
Mais ce que ça n'est pas de l'implicite,
parce que quand on dit une belle architecture,
c'est une architecture qui va être lisible
par une personne de manière à fait.
Non forcément, c'est une architecture
que soient les plus performantes possibles, peut-être.
Mais moi, il y a cette idée d'une industrialisation
implique aussi une sorte de standardisation.
T'as vu le standard des boulons et des prises et des trucs et des machins ?
Oui, il y a des standardisations, mais il y a des standards pour tout.
Donc tu te retrouves aussi à avoir une connexion monstrueuse de standard.
C'est pour ça qu'on a plein de langages de programmation,
plein de manières de programmer des trucs.
C'est que chaque langage de programmation, chaque paradigme,
il a été fait parce qu'il y avait un besoin derrière.
Je te rejoins un peu, c'est peut-être un kink un peu d'ingénieur,
mais moi, je trouve que l'industrielle, c'est beau.
Moi, je veux des puites reliées dans mon jardin.
Une machine outil à servi qui sort 200 pièces par heure
et qui ne faut avoir jamais, c'est beau.
Il est beauté dans le saut, en effet.
C'est calé et pourquoi ça marche ?
Parce qu'on a des standards, parce qu'on a des autres trucs.
J'ai envie de dire qu'on serait dans un monde où le domaine de l'IT,
c'est exploratoire, c'est quelque chose de nouveau.
On est en train de découvrir au début d'Internet,
je dirais que se dire qu'on est des artisans, on essaie des choses
et puis on peut passer 10 ans à sculpter un truc parce que c'est joli.
C'est peut-être le bon moment.
Là, en ce moment, on a quand même une crise de la productivité.
C'est-à-dire qu'il y a énormément de choses qui se numérisent
et en plus, on est poussé par le début de la discussion
qui est qu'on a besoin d'autonomie sur un certain nombre de secteurs.
Donc, de mon point de vue, c'est effectivement pas le moment
de se dire qu'on fait que des trucs beaux,
faut faire des trucs efficaces et il y a de la beauté dans l'efficacité.
Après, si je peux rejoindre ton point et puis à la fois m'attaquer moi-même,
c'est-à-dire qu'on parlait de côté, je veux faire quelque chose de nouveau
parce que j'ai l'impression d'avoir un besoin relativement unique.
Et par ailleurs, le côté de ta machine-outil,
finalement, ce qu'on apprend souvent dans la douleur avec l'expérience,
c'est quelque chose qui marche comme ça comme une machine qui n'ont jamais en rade,
c'est qu'elle a été éprouvée, elle a déjà passé le flip-step.
Et donc quelque part, elle est stable, elle bouge plus.
On n'a pas changé la technologie de construction de cette machine.
Et donc, de facto, effectivement, elle fait son boulot bien.
Mais le jour où elle est plus assez rapide et que finalement, on doit passer au-delà,
il y a un petit moment d'incertitude et qui n'est pas facile à détecter.
À quel moment on dit qu'il faut repasser en mode craft-nouane un certain temps,
retester quelque chose, mais de toute façon, il va falloir le ré-approuver
pour retrouver ce même mode de stabilité, parce que c'est vrai que c'est un petit côté frustrant
de se dire qu'on n'a pas de fondation.
Et ce n'est pas facile, ce n'est pas facile à détecter,
et surtout pas en plus que nous, on a les bonnes réponses,
parce qu'on s'est refusés à le faire par moments,
on s'est autorisés à le faire par d'autres.
Mais il y a un moment où il faut se dire,
la fameuse machine-là, elle marche super bien,
mais si je la fais marcher trop vite, c'est intonable.
Et tant que je ne change pas de techno,
c'est intonable aussi d'essayer de la faire évoluer.
Et donc, on a une industrie qui n'est pas facile,
parce qu'en gros, tout comme on avait dit tout à l'heure,
tout le monde veut tout le temps, c'est que d'un côté, nous, développeurs,
on veut pouvoir un peu tout péter tout le temps,
et avec cette super liberté, que finalement,
on n'est pas forcément nécessairement une bonne idée de se dire,
c'est-à-dire, je fais mon schéma d'archie
avec toute la liberté, la variabilité qui va avec,
et quelque part, à certains moments, on peut dire,
non, mais là, la machine ne doit pas tomber.
Donc, c'est un jeu d'équilibre.
Ah mais, ce n'est pas de tout facile, c'est clair.
Et il y a tous ces facteurs-là,
qui ont une industrie,
où il y a des nouveautés qui apparaissent tous les semaines,
et on est tous tentés par les hype-driven-development.
Oui, qui sont pas aussi bonnes.
On a tous les vies de tester, les derniers routiers,
les derniers langages, les derniers frameworks.
Et après, il y a un truc qu'il faut avoir en tête aussi,
c'est que les belles machines outils
qui sont capables de sortir 10 000 pièces à l'heure,
souvent, c'est des machines qui ont été faites
sur mesure pour l'usine, où elle est installée.
On est d'accord.
On a pas de deux dans le monde.
Mais ça n'était fait sous mesure,
et basse à des parties standards, moi, c'est...
Mais en informatique, on est standardisé partout.
C'est juste que, on a...
les choses que l'on va construire par rapport à ces standards
ne le sont plus parce que justement, on se dit,
tiens, moi, j'aurais envie que le standard fasse un peu plus,
ou il fasse ça différemment, ou il fasse 20.
Mais en vrai, nous, les briques de base de l'informatique,
par exemple, c'est un système d'exploitation Linux,
une G-Lypse, et après, on vient construire plein de choses par-dessus.
Mais l'informatique est déjà standardisée.
En fait, là où je te rejoins complètement,
c'est ça qui est un peu difficile,
c'est qu'il y a beaucoup de news,
beaucoup de phénomènes d'annonce sur des techno, etc.
Mais finalement, pour les gens qui étudient les briques de base,
c'est les bas niveaux, alors que ce soit soit implémenté,
soit même au niveau des algorithmes que vraiment on utilise,
on remonte souvent vachement loin dans le temps,
pour avoir fait des bases de données, on arrive vite sur des guides,
des décennies d'historie, et on dit, à la vache,
il n'y en a pas tant que ça, en fait.
C'est-à-dire que les vrais briques de base, en dessous du dessous,
il n'y en a pas tant que ça.
Et finalement, on parle souvent de vraping, de vraping, de vraping,
et j'ai un peu l'impression que par moments,
on est une industrie qui tombe dans une complexité existante,
pas à cause de la brique de base,
parce que finalement, il n'y en a pas tant que ça,
et en général, il prend le temps d'être maturé,
mais parce qu'on l'a vrapé, réutilisé, redrafté,
et c'est plutôt le Tome ML ou le Yamel au milieu
qui a explosé un peu un vol, parce que l'inventation,
pour sélectionner, je ne peux pas me faire que des potes.
Mais l'inventation, c'est un téné certain fil.
Et c'est peut-être pas toujours la bonne idée
pour avoir quelque chose de robuste,
et c'est là aussi, c'est dommage,
parce que finalement, la libre en dessous,
qui était codée depuis 10 ans, avec je ne sais pas quelle approche,
on s'est plus poussé sur Gellipcée seulement,
elle, elle n'avait pas du tout le problème, en fait.
Donc, petite frustration par moment,
parce qu'au final, on parle souvent de tech,
mais finalement, on n'est pas si souvent que ça,
on rapport avec un ouvert-algoût et un nouvel tech.
Mais pour donner un exemple, parce que comme ça,
on va vous insister avec des sujets de sécurité,
vous savez, avant Noël,
il y a eu une faille de sécurité dans les serveurs component de React.
Normalement, c'était un pièce dans son framework front.
Ça fait tomber énormément de sites,
parce que derrière, ces serveurs component de React,
beaucoup de monde qui utilise React n'utilise jamais,
était embarqués dans Noxt.
Et Noxt est devenu le framework coutillage,
plus ou moins hype, pour faire des applications web.
Et c'est le framework de Vache et Vercel.
Donc, conclusion pleine de sites,
que la plupart c'est les blogs statiques,
donc Yannick parlait avec une petite base
de données à côté pour un peu de dynamisme,
il s'était tous trués à cause de cette dépendance-là,
mais tu vois que la plupart de ces sites-là
n'avaient strictement aucune besoin d'embarquer à Noxt complet.
Et même si l'embarquait,
les serveurs component de React n'étaient utilisés
comme un sous-produit de framework dans lequel ils s'étaient.
Et donc là, quand je parle de hype-driven development
et de niveau de complexité,
moi peut-être que je vais vieillir,
je vais tenter de me dire plus de plus amplifier,
plus de plus revenir à ce composant de base
dont tu parlais à réduire les coûts d'extraction
ni à te porter à la fin.
Les coûts d'extraction sont bien quand ils sont nécessaires,
quand ils sont là pour des raisons de
où tout le monde les fait,
là c'est là où ça ne me pose plus de souci.
Donc je crois que là-bas,
on est tous les quatre et plus ou moins d'accord
sur le constat quoi.
En fait, sur la complexité...
Accidentaire que dis-tu François.
C'est ça, un effet de bord aussi non négligeable
et l'attaque via React dont tu parlais
et un symptôme,
c'est que ça crée des angles morts monstrueux
qui permettent de faire des supply chaines attaques
qui sont effrayantes.
Dans le cas de Q,
moi il y a un truc que je ne donnerai pas de nom
mais il y a énormément de projets de software
qui sont package pour être installés dans Q
et qui mettent des cluster roles.
C'est dans le airbag de Q
le truc qui permet de définir des droits d'accès
aux autres ressources
et qui n'est pas restreint par Name Space.
Ils mettent des cluster roles qui sont effrayantes.
Il y a énormément de logiciels
qui n'ont pas besoin d'être administrateur sur cluster
que je vois demander les accès en liste get watch
à tous les secrets du cluster.
Si moi j'arrive à pirater n'importe quel éditeur
qui fait ça, je fais une release,
tous les mecs qui l'installent,
j'ai la main sur leur cluster,
je peux me générer des access, je fais ce que je veux.
Personne ne lisse les permissions quand il les installe.
C'est vraiment effrayant de ce côté là.
On est dans un milieu où on parlait des stack web
quand même pas mal d'attaques,
même carrément au niveau des installations des packs NPM
dans l'historique proche,
on avait pas mal de quatre vecteurs comme ça.
Si on est honnête,
on prend des projets
même pas si compliqués que ça,
on arrive à des centaines de milliers de dépendances
dans le coût de NPM.
Ce n'est pas la faute de NPM,
je ne vais surtout pas charger sur leur dos,
mais c'est devenu quelque chose de standard,
d'acceptable.
Et alors pareil, peut-être que je vieillis,
mais je vais dire le côté de four à la liste
de qui je dépends,
de qui est-ce que j'utilise
pour savoir un peu où ces fameux angles morts.
Ça, c'est quelque chose qui n'est plus du tout dans le giron
où on se dit, bon, ce n'est pas grave,
on bâtit sur des briques existantes.
Et j'avoue que je plaide aussi coupable
d'un point de vue enseignement,
j'ai été le premier à enseigner les phrases suivantes
en disant, ne refaites pas quelque chose qui existe,
vous vrapez, vous vrapez, vous packagez.
Et il semblerait que finalement,
cette approche-là a été largement suivie
puisque c'est ce qu'on a maintenant sur les frameworks,
mais avec un jusqu'au boutique qui nous montre
que finalement, elle n'a pas forcément raison sur tout.
C'est trop.
Je sais pas si on ne le voit pas.
Je me souviens, à mon époque, quand on faisait de Java,
tu allais chercher chaque bibliothèque
de laquelle tu dépendais sur le site web,
tu te baladais sur Apache Commons
et tu récupérais toutes tes bibliothèques
et les dépendances de tes bibliothèques
et tu allais y un par une.
Et quand tu voulais mettre les jours,
tu allais aller à nouveau sur le site,
tu les récupérais.
Et petit à petit,
on a commencé à pouvoir faire ça
de façon automatique, mais on ne les voit plus.
Et au moment où tu ne les vois plus,
tu écris 3 dépendances sur ton fichier,
tu sais pas si derrière,
il va te remettre 3 ou 300 ou 3000.
Surtout avec un réseau internet rapide,
c'est quelques secondes de plus de tant.
Et il y a quelque part,
une cachée de complexité,
une petite museuse sur ce côté-là,
c'est devenu acceptable
parce que c'est facile
de faire la première,
de voir qui fait le moment,
ou de faire avec un petit commande,
aller, on va récupérer tous les dépendances.
Et je n'ai pas fait de la meilleure,
mais de la meilleure dépendance de mon app.
Donc il y a quelque part,
ça a été tellement facilité
et on en revient à ce qu'on disait tout à l'heure.
On est une industrie qui s'est beaucoup standardisée.
Et c'est top, je veux dire,
je suis le premier à part gréter
d'aller chercher mes jards à la main.
C'était clairement pas un moment
où je me sentais mis en avant en tant qu'ingénieur.
Donc non, c'est très très bien qu'on ait standardisé ces ripos,
les endroits où on peut publier des choses
et que les gens communiquent,
il y a tout un tas de projets
qui échangent des briques de base, c'est top.
Mais la question,
c'est comment est-ce qu'on fait ça ?
Alors pour des exemples joués,
ce n'est pas forcément un très gros problème.
Pour certaines applications, ça commence à l'être.
Et si on parle maintenant de sous-20P numérique
ou de cas d'applications,
donc nous, dans notre cas,
pour aider à gérer des réseaux publics,
ça pose quand même d'autres questions.
Parce que là, tous les coups,
les deux devs qui étaient là il y a 10 ans,
mais qui ne sont plus là, qui ont fait le package
dont le cache dépend,
ça pose quand même pas mal de questions
sur la soutenabilité de mon logiciel dans le futur.
Donc il faudrait qu'on cartographie,
qu'on enseigne un peu plus ça en disant
il y a plus de choses qu'avant, c'est top.
Apprenez beaucoup plus à savoir qui fait quoi.
Parce que vraiment, c'est plus important qu'avant.
C'est pour ça qu'il faut outiller
Satoulchain.
Par exemple, nous en Rust, on a des outils
comme Cargo Audit.
Moi, à chaque fois que je fais un nouveau déploiement
sur la CIA,
il y a le Cargo Audit qui se lance
et qui me dit toutes les crates
qui sont dépréciées.
Genre l'autre jour, il y a une personne
qui a fait un burn out mental.
Il en avait marre de gérer une crates.
Et du coup, il l'a arrêté complètement
de mettre à jour la crates
et il a dit, débrouillez-vous,
je vous laisse la souveraineté du truc.
Ça veut dire que n'importe qui
peut retourner et récupérer le projet
et commencer à faire du supply chain
sur le truc.
Et bien ça, directement,
c'est arrivé dans ma boîte mail.
Et puis on a dégagé la dépendance.
Mais ça, c'est tout le langage.
C'est ça, MPM et MPM Audit
qui te montrent les dépréciés.
Le problème, c'est que si tu as un projet
ou si tu dois t'installer un projet open source
dans MPM Audit, il te dit
il y a 47 projets,
quand 7 dépenages de précie
dans ton projet,
dans la plupart des cas,
tu vas pouvoir faire grand chose.
Ça dépend ce que je fais de ton projet.
Si c'est un projet qui est, entre guillemets,
ton site project que tu fais tourner le week-end,
bon oui, il y a des dépréciés,
c'est pas grave.
Si tu commences à faire des choses industrielles
et que tu as plein de dépendances
qui sont plus maintenues depuis 10 ans
et qui peuvent avoir des failles de sécurité,
tu prends un risque.
Ça c'est toi qui t'es consentie, mon ami.
Je sais pas, quand tu construis un pont,
tu prends pas des clous rouillés,
tu prends des clous qui tiennent la haute.
Et puis tu t'interasses à la compétition
de la ciédéclou aussi.
Également.
Mais si tu es le sous-traitant
que l'on dit,
il faut que les ponts sortent en trois jours
et après tu vas construire les ponts suivants.
C'est aussi ça.
Et simplement aussi la complexité.
Aujourd'hui, je t'ai parlé de mon histoire
de cet étudiant auquel je sais d'apprendre
à faire des fronts,
mais je pourrais parler de plein d'autres cas aujourd'hui.
En plus, j'adore les léles,
mais ça fait que beaucoup de monde
qui se dévouent avec ça et restent plus en surface.
Ça veut dire que cet étudiant
va, en parler d'industrialisation,
peut-être que le grand boulot
de l'industrialisation de notre industrie
sera qu'on se concentre plus
sur la considération de fonds
de comment tu fais pour que tu n'applies
soit maintainable,
comment tu fais pour que tu as su que tu te dépendras.
Et pourquoi la métallurgie,
elle a mis 20 ans à s'industrialiser
et nous en 60 ans on n'a pas réussi à s'industrialiser.
Il y a quand même un truc derrière qui fait
que tu as des fonds de la industrie




Il y a le fait qu'on peut refaire
un des éléments qui fait que ça change.
Mais pour pousser le message,
c'est bien que tu fasses le parallèle, Yannick,
parce que c'est là où je voulais arriver.
En fait, sans remettre en question
nécessairement l'intégralité de la liberté
qu'on a d'experimenter et de faire des choses,
je pense que quand on décide d'aller quelque part
et de commencer une v1 d'un produit,
de se dire qu'on y va,
il faut que le truc soit bien,
on peut commencer à s'inspirer des autres industries.
Il y a la manufacture d'un côté,
mais il y a aussi plein de sources d'inspiration
qui sont exceptionnelles.
Je voyais, on disait tout à l'heure,
tous les systèmes n'ont pas besoin d'être online
tout le temps et très existants.
Il y en a certains où ça doit être le cas.
Et pour ça, je bosse un peu là-dessus
sur la partie compute virtualisation chez nous,
où globalement tout est basé sur la virtualisation.
Comme on dit, une vm est un événement
qu'il ne doit jamais échouer.
C'est inacceptable, parce que c'est le coeur
de notre côté dynamique et de notre capacité à repartir.
J'ai découvert des trucs super intéressants
du côté du nucléaire, sur la résilience,
et notamment un mode ordre qu'ils ont
qui est redondant ces diversifications.
Pour être sûr que ça marche
et pour battre les stats et la loi de Murphy,
non seulement quand ils ont une fonction
à opérer, ils la redombre avec un autre système,
mais en plus, ils changent la nature profonde
du système qui effectue la redondance.
Et après, il y a plusieurs étages suivant ce qu'on veut faire.
Et ça, je trouve que c'était une piste assez intéressante
pour me dire que les systèmes de failover
ou de backup, ou de si ça ne marche pas,
on peut descendre à des choses plus simples
et qui sont différentes.
Par exemple, la chose qui m'a énormément inspirée,
c'est que, si le refroidissement primaire d'une centrale foire
y a un refroidissement secondaire,
un système qui prend l'eau ailleurs,
parce que si la grille est bouchée d'aspiration d'eau,
on va la chercher ailleurs.
Et puis le troisième, il n'y a plus besoin de pompes.
C'est en fait dans un réservoir qui est en hauteur,
et c'est la gravité qui fait le boulot.
Et de là, ce que la gravité foire, normalement,
on a de la marche.
Ça se passe à peu près.
Il y a des aspirations semblables d'aller au nautique,
par exemple, d'aller au nautique, de sa vieille.
Mais c'est des choses que je pense
que si on fait que ça se devienne
en industrie vraie,
tu parles de la vieille.
Justement, c'est l'endroit qui est le plus industrialisé
de notre profession.
La vieille utilise des langages de programmation en temps réel.
Et du coup, l'APL, c'est pour ceux qui connaissent,
ces langages-là, ils ont commencé il y a 60 ans,
ils sont toujours là et ils tournent toujours.
Oui.
Et c'est vrai que par contre, c'est là
où on en revient à un bout de la discussion de tout à l'heure.
La standardisation, c'est bien, mais la résilience,
en tout cas, ce dont on parle dans les autres industries,
vient exactement, certes, de standardisation,
mais diversification quand même.
Et en particulier, au moins de l'architecture.
Ce sont des choses qu'on fait assez peu en informatique,
puisque nous, en général, on fait plutôt l'inverse,
on fait une standardisation à outrance.
Et si on a un cluster qui est bien homogène, on est content.
Ce qui fait que quand on va avoir une montée en charge,
on est un peu sûr que tous les hostes vont réagir pareil.
Avec un peu de chance, le load balancer va bien faire en sorte
qu'à la même minute, une seconde, des trois,
ou quatre, ou cinq qui sont en fail-over,
vont tourner en même temps.
On a effectivement beaucoup de choses à apprendre
des autres industries,
de se dire, ces choses-là,
qu'on était faites parce qu'à l'époque, on ne pouvait pas refaire,
et que redémarrer un système industriel,
surtout comme une centrale, qui était bien sûr,
bien trop coûteux,
là où nous, on s'est permis de le faire,
et qu'on ferait peut-être bien, dans les systèmes logiciels,
d'apprendre ça aussi.
Mais ça veut quelque part dire
qu'il faut qu'on accepte d'avoir plusieurs façons de faire,
entre la plus simple et la plus compliquée.
Donc on revient au tout début de la discussion,
en disant, s'il n'y a qu'une seule,
si j'ai que la bonne DB,
ou la...
Le marteau rouge.
Le marteau rouge, ce sera probablement pas suffisant.
Donc il faudra au moins un verre et un bleu,
ce serait bien.
Et même peut-être une masse,
des fois qu'il faut taper un peu plus fort.
Voilà, et il y a deux...
On était partis sur une petite discrétion,
et on a fait tout un épisode de ma si,
avec quoi je vous avais prévenu,
c'est de souyé,
qui est passionnée.
Bah...
Je pense qu'on peut arrêter là pour aujourd'hui.
L'épisode précédent,
je l'avais demandé à François et Musique de Fan.
Maintenant, c'est un tour.
Qu'est-ce que tu veux mettre dans les oreilles de nos auditeurs
pour ce type d'épisode ?
Moi, il y a un truc que j'écoute pas mal.
C'est un artiste, il s'appelle Makoto-san.
Qu'on ait eu la chance de voir en live
au jeudi du Port à Brest,
puisqu'il y a une partie de l'équipe de Clémore qui est basée à Brest.
Et c'est de l'électro un peu sympa,
avec des rythmes différents.
Par exemple,
Guadouard,
chez me la dévière.
Ok, tu vas me mettre ça par écrit,
tu me mets un petit message,
je l'ai copie de Lélian.
Et avec ça, merci encore François de voir ce type de choses.
Je passe au super moment, merci Yannick,
merci Pandan, et j'espère que tu sais plus
comment je fais cet épisode.
Merci à nos auditeurs de Terella,
à très bientôt.
Merci, salut.