Mettre le dev en musique

Bruno:
Notre métier est incroyablement complexe. Il suffit de regarder l'audimat de ce podcast. À part quelques gens comme nous, personne ne l'écoute. Et pourtant, malgré l'immense complexité et valeur de notre métier, partout dans le monde, il existe des devs qui mettent tout leur travail à disposition gratuitement. Parfois des petites librairies sans intérêt et parfois des projets entiers, hyper pointus qui font avancer l'humanité tout entière. Mais alors, notre métier serait-il le même sans l'open source ? Pourquoi mettre tout son travail à dispo de touts ? Et surtout, comment faire en sorte pour que cette philosophie ne meure pas à l'ère des LLM ? Pour répondre à ces questions de partage, je ne reçois pas Gandhi, mais il s'y connaît en paix intérieure. Fabien, bonjour.

Fabien:
Bonjour.

Bruno:
Alors Fabien, est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?

Fabien:
Bien sûr, avec plaisir. Donc Fabien, je suis entrepreneur et ingénieur développeur, on va dire comme ça. J'ai commencé à faire du développement, je crois que j'avais 7 ou 8 ans. Et puis après, dans mes études, je n'ai pas fait des études du tout autour de l'informatique. J'ai fait mon premier stage, par contre, en faisant un site web, un intranet. À l'époque, c'était assez novateur. En Angleterre, là où j'ai découvert un peu le développement web en perle. Perle et Windows, une combinaison un peu bizarre. Et ça m'a passionné. Du coup, j'ai continué ça. Et j'ai allié à la fois ma passion et mon goût pour l'entrepreneuriat. Donc, je n'ai jamais été salarié, en fait. J'ai toujours été entrepreneur. Et donc sur les 25 dernières années j'ai créé 4 sociétés tout autour du web, et voilà j'ai vendu les 4 donc très content de ce que j'ai pu faire sur les 25 dernières années et aujourd'hui je partage mon temps encore sur l'open source encore développeur au jour le jour et puis aussi faire la transition sur les différentes sociétés que j'ai pu vendre et notamment en ce moment, sur une société qui s'appelle plateforme.sh slash Upson, pour laquelle je gère la partie advocacy.

Bruno:
Donc, tu as effectivement, pour ceux qui ne le sauraient pas, tu as quand même un pied dans l'open source qui est quand même assez important, parce que tu représentes un projet que je pense quasiment tous les développeurs connaissent ou en tout cas, ils en ont entendu parler. Donc, tu es à l'origine du projet Symfony. L'idée de cette discussion, c'est de voir effectivement comment est-ce que l'open source a évolué entre ce que c'était quand quand tu étais dedans au début des années 2000, est-ce qu'elle s'est pu devenir aujourd'hui ? Mais j'étais aussi curieux de cet impact de l'open source, parce qu'en fait, moi, de manière un peu étrange, quand je pense open source, donc effectivement, cette notion de partage, de diffusion de savoir et de valeur, je ne peux pas m'empêcher de penser aussi à Stack Overflow, qui pour moi est un moyen colossal aussi d'apprendre des trucs et d'avoir à disposition du contenu et de la valeur tech. Et on voit bien qu'avec l'arrivée d'LLM, l'audience de Stack Overflow chute parce qu'en fait on a ces outils-là qui sont capables, je mets des guillemets, de coder à notre place et de nous apporter ce support-là. Et donc, je serais curieux, dans un deuxième temps, on évoque aussi ton point de vue sur ce que ça peut apporter ou au contraire retirer au monde de l'open source. Est-ce que du coup, dans un premier temps, tu peux nous raconter un peu, toi, ta découverte de ce monde-là et qu'est-ce qui t'a amené à vouloir mettre Symfony en open source quasiment Day One ?

Fabien:
Ouais. Alors Day One, je ne sais pas, mais en tout cas, l'open source pour moi, avant tout, c'était une curiosité. Donc quand je faisais du Perl, je me posais la question de tiens, j'utilisais déjà beaucoup de briques open source. Donc l'open source, ça existe depuis très, très longtemps. Et j'utilisais beaucoup de briques et je me disais tiens, c'est intéressant de pouvoir partager. Et en fait, l'open source, c'est une manière aussi d'apprendre super rapidement parce qu'on voit ce que les autres font. Généralement, c'est du code qui est plutôt bon. En tout cas, il y a eu beaucoup de gens qui l'ont regardé, qui l'ont amélioré au fil des années. Donc, c'est du code qui est plutôt intéressant. Et je voulais apporter ma pierre à l'édifice et comprendre un peu les mécaniques de l'open source. Pourquoi les gens font ça ? Qu'est-ce qu'ils en recherchent ? Qu'est-ce qu'ils en retirent ? Donc, j'avais commencé à mettre quelques bibliothèques en open source, donc en 98, 99, quelque chose comme ça. D'ailleurs, je serais assez curieux de voir, mais je suis quasiment sûr qu'il y en a qui sont encore disponibles si on va voir sur le CEPAN Perl. J'en ai d'ailleurs basculé à un certain nombre de gens qui continuent à les maintenir. Et après, la première société que j'ai créée, ou qu'on a créée à plusieurs d'ailleurs, c'était une société, ce qu'on appelait une agence web à l'époque. Je ne sais pas si on appelle ça encore agence web.

Bruno:
Maintenant on dit agence digitale.

Fabien:
Agence digitale, oui c'est vachement bien. Donc on appelait ça agence web bêtement à l'époque. Et en fait, on utilisait beaucoup de perles. On s'est rendu compte qu'en France, on utilisait beaucoup le PHP. Et j'aime pas le PHP. Et à chaque fois que je parle à quelqu'un, je dis « moi, j'aime pas PHP ».

Bruno:
C'est toujours un peu surprenant quand toi, tu dis ça.

Fabien:
Et en fait, je fais pas du PHP parce que j'aime bien le langage. Et je faisais pas du Perl parce que j'aimais bien le langage. Et les gens font certainement pas du Java parce qu'ils aiment bien le langage. Et c'est bien si on peut allier à la fois le langage et la finalité. Mais en fait, moi, je l'ai vu comme une opportunité business, avant tout. Une opportunité de business. Ceci étant, je n'aime pas le PHP 4. Je ne peux pas parler du PHP 3, je n'ai jamais regardé, mais pas le PHP 4. Et en fait, quand le PHP 5 est arrivé sur le marché, je me suis dit, tiens, il y a quelque chose. Il y a eu un effort qui était fait. C'était au moment, en fait, où Ziv et Andy ont repris un peu la main. Enfin, en tout cas, on travaillait avec Rasmus pour pouvoir améliorer notamment la façon dont on gérait les objets et les classes, en PHP, je me suis dit il y a un truc qui est solide, il y a un truc j'ai envie en tout cas d'en apprendre plus du coup il y avait un peu d'effervescence, donc il y avait quelques frameworks qui existaient à l'époque autour du MVC, donc il y a un design pattern, modèle view controller et donc j'ai fait quelques expérimentations en juillet 2004 il y avait aussi un ORM qui s'appelait Propel à l'époque. Donc j'ai fait des tests comme ça et puis j'ai laissé tomber j'avais fait un proto pour totale, je crois, à l'époque, qui n'a rien donné. On n'a pas gagné le projet. Mais en tout cas, c'était... Oui, il me faut toujours quelque chose pour tester. Il me faut un projet. Je ne peux pas tester comme ça. Je veux confronter ce que j'utilise avec la réalité. Est-ce que ça marche ou ça ne marche pas dans la vie réelle ? Et je pense que c'est ce qui a fait après, d'ailleurs, le succès de Symfony initialement, c'est que ça réglait des problèmes que les gens avaient dans la vraie vie pour développer des projets entreprises. Symfony, l'un des seuls projets que je connaissais à l'époque qui, en fait, avaient été créés pas par un étudiant. Il y a beaucoup de projets open source qui sont créés par des étudiants. Évidemment, on a plein de temps disponible, donc voilà, et puis on veut se faire connaître. Et donc, aujourd'hui, c'est encore le cas.

Bruno:
Et puis aussi, on ne travaille pas pour une entreprise qui a besoin de conserver un avantage concurrentiel en gardant son code propriétaire.

Fabien:
Oui, et comme j'étais le patron, c'était assez facile. C'était moi qui faisais le choix. Donc, on a fait ça. Donc, j'ai créé... Vacances de Noël, mon associé me dit, tiens, on a un problème, on a un client qu'on doit sauver quelque part parce qu'on doit faire un site en un mois. Je suis sûr que c'est encore le cas aujourd'hui.

Bruno:
Ça n'a pas changé.

Fabien:
Ça n'a pas changé. Du coup, j'ai passé mes vacances de Noël à faire ça. Pas créer le framework, mais créer la solution pour gérer un site de e-commerce avec le back-end qui va avec. Et c'est ce qu'il y a de pire au monde à faire, honnêtement, parce que, on vend pas des produits enfin on vend des produits avec plein de facettes différentes donc que ce soit la couleur la taille homme femme enfin bon il y a plein plein de facettes différentes donc j'ai réalisé un back-end assez générique, et assez compliqué assez complexe, fun fact l'admin gen qu'on peut avoir aujourd'hui dans le monde Symfony donc 25 ans après est pas aussi puissant que ce que j'avais réalisé en Gillesman à l'époque bon mais c'est aussi quelque chose qui était pas générique versus quelque chose qui doit être générique mais anyway Oui. Et donc, une fois que j'ai fait ça, je me suis dit, tiens, comment on peut capitaliser ? Et en fait, je pense que le mot-clé, c'est ça. Comment on fait pour capitaliser ce savoir, ce développement ? Comment on peut le réutiliser ? Et comme tu disais aussi, quand on parle de projets pour les clients, les clients, ils n'aiment pas tellement avoir des solutions propriétaires, parce que ça veut dire qu'ils sont pieds et mains liés avec le prestataire. Ou dit autrement, on appelle ça la réversibilité aussi. donc comment on peut avoir de la réversibilité sur les applications qu'on développe donc assez rapidement je me suis dit il faut que Symfony soit open source à l'époque ça s'appelait Sensio Framework donc SF Sensio Framework puisque la boîte s'appelait Sensio à l'époque, et donc on a travaillé pendant, 3-4 mois à écrire la documentation à être sûr que le code était, générique donc on a supprimé plein de trucs pour la première version. On a voulu donner un nom, Et d'entrée de jeu, je me suis dit, il faut faire une différence entre le monde de l'open source et ce qu'on donne gratuitement d'open source, et la partie commerciale. Donc Sensio, Symfony. Et si parmi l'audience, il y a des gens qui sont un peu vieux, peut-être qu'à l'époque, les gens me disaient, mais Fabien, en fait, Symfony, ça s'écrit pas comme ça du tout. C'est PH, en fait, c'est pas un F. Ils disent, oui, oui, je sais, je sais, je sais. Mais le truc, c'est qu'à l'époque, on avait pas les mêmes spaces en PHP, et donc toutes les classes étaient préfixées par quelque chose. Pour qu'il n'y ait pas de concurrence entre deux requests d'un framework et requests ailleurs sur une librairie HTTP ou je ne sais pas quoi. Et donc, toutes les classes étaient préfixées par SF, Sensio Framework. Et quand on l'a mis en open source, je me suis dit, mais je ne veux pas renommer. Comme tout développeur, en fait, je n'ai pas envie de m'emmerder la vie. Je n'ai pas envie de faire ça. Et donc, je me suis dit, il faut que je trouve un nom avec un S et un F. Vous me croirez si vous voulez. Et à l'époque, il n'y avait pas de l'élème, il n'y avait pas de chat GPT pour dire « Tiens, donne-moi des noms sympathiques pour un framework avec un S et un F dedans. » Donc j'ai pris le dictionnaire, j'ai fait des petites recherches, etc. Et c'est super compliqué. Et je ne sais plus pourquoi, mais à un moment donné, boum, on a un truc. « Ah, Symfony, Symfony, ça marche bien. Ça véhicule aussi les valeurs que je veux apporter à ce framework. » Et du coup, je me suis dit « Bon, Symfony, PH, F, allez, go. » Et honnêtement, j'aimais bien ce petit côté dérangeant de la faute d'orthographe. Ce petit côté, allez, je fais un truc un peu différent.

Bruno:
Mais ce qui est d'autant plus frustrant, c'est que comme tu es en PHP, le PH avait quand même un peu son mot à dire. Enfin, tu vois, il aurait eu sa place, en fait, dans le mot.

Fabien:
Ah, mais je n'y ai jamais pensé.

Bruno:
C'est sérieux ?

Fabien:
Non, je n'y ai jamais pensé. Ceci étant, ceci étant, j'y ai pensé il n'y a pas... Enfin, je n'ai jamais fait ce lien-là, ce rapprochement-là. Même si dans le monde PHP il y a des éléphants et puis tout le monde a fait son éléphant et puis nous on a fait nos éléphants, bon bref il y a deux ans j'ai dit j'en ai ras-le-bol les éléphants donc on arrête les éléphants parce que ce que les gens ne comprennent pas c'est que les éléphants moi il faut que je les stocke, et les éléphants on ne peut pas en acheter 100 donc on les achète par 2000 donc c'est des caisses et des caisses donc c'est des enfin c'est trois fois ce studio où il faut stocker les éléphants avant de les écouler les vendre les machins et puis le gens ils te donnent du cash, ils vivent les cartes bleues c'est un enfer absolu les éléphants. Donc il y a deux ans la conférence à, je sais plus, à Bruxelles, non non non c'était à Disney, on vend le dernier éléphant et je dis plus jamais des éléphants c'est fini, ça fait 15 ans qu'on en fait c'est terminé, je veux plus en entendre parler et évidemment six mois après, mon équipe vient me voir et me dit, Fabien en fait on a pensé à faire un poney, J'ai dit, non, non, attendez les gars, vous m'avez pas compris, c'était les peluches en règle générale, c'est pas l'éléphant en particulier.

Bruno:
C'est pas l'animal le problème.

Fabien:
Non, l'animal c'est pas le problème, c'est vraiment de faire des peluches, j'en ai marre. J'ai dit non, je veux pas faire de poneys en plus, non, je veux pas faire de poneys. Bon, ok, et puis ils savent que je suis un peu influençable, donc ils sont venus à la charge une fois, deux fois, trois fois, quatre fois, et apparemment, mais j'ai pas souvenir, mais apparemment à un moment donné j'ai dit, oui, comme ça, mais vraiment, oui. Et je me suis retrouvé avec des éléphants, avec des poneys, pardon. Et pourquoi je te raconte ça par rapport à PHP et Symfony, c'est que du coup on appelle ça le Sympony Ah d'accord et donc là tout d'un coup je suis en train de réaliser que si on avait gardé le PH et le P ça faisait un Symfony.

Bruno:
Sympony, bon bref.

Fabien:
Jamais été très bon en marketing.

Bruno:
Ce qui est marrant c'est que dans cette histoire on retrouve aussi, entre guillemets la fausse paresse du développeur qui pour éviter le refactoring va faire tout un tas de recherches pour essayer de trouver un moyen de garder le SF alors que tu aurais peut-être pu très facilement en Perl parce que c'était aussi ta technique d'origine faire un simple regex pour virer tout tes SF quoi.

Fabien:
Find pipe Perl moins P moins I moins E S dièse quelque chose dièse.

Bruno:
Autre chose G tu l'as déjà boum je l'ai je connais par coeur je le fais tous les jours donc.

Fabien:
Ouais mais ceci étant ceci étant j'ai toujours cru aux marques. Donc au fait d'avoir un nom qui signifie quelque chose. Donc Sensio, la première boîte qu'on a créée, ça vient de Sensilio, je le prononce certainement très mal parce que je ne parle pas espagnol, qui veut dire simple. La simplicité, c'était au cœur de nos préoccupations. Bon, 20 ans après, je me dis que tout le monde veut faire des trucs simples, donc ça n'avait pas de sens, mais en tout cas, il y avait cette idée-là. Et Symphonie, je voulais aussi que ça véhicule une certaine image de ce qu'on faisait. Donc, ce n'était pas que de la paresse. c'était pas que ça, c'était aussi d'avoir quelque chose qui soit intéressant et que les gens comprennent et que ça marque les gens en fait Très bien.

Bruno:
Alors on s'est un peu égaré du sujet parce que le but c'était quand même de parler du monde de l'open source.

Fabien:
Ceci étant, tu m'as dit nos limites.

Bruno:
Oui mais c'est vrai c'est une conversation du coup donc ça a été quoi pour toi, je comprends cette impulsion de te dire on veut pas que nos clients soient Soit logged in, donc on le met en open source. Mais j'en ai pas qui me viennent en tête, mais ça a été vraiment ça pour toi, le seul moteur de te dire, il faut le mettre en open source. Tu peux le mettre en mode licensing, tu peux le proposer à d'autres boîtes. Il y a d'autres moyens.

Fabien:
Oui, complètement. Je pense que le facteur principal, c'est déjà de se dire qu'un framework, déjà, il ne peut pas être GPL. Donc déjà, par rapport à la licence, on a pris une licence extrêmement libérale à MIT, donc on peut tout faire, à part me piquer la marque, mais tout le reste, on peut le faire. Et à part virer les copyrights, évidemment, tout le reste, on peut le faire. Donc, c'est extrêmement libéral. Et je pense que c'est la seule façon de commercialiser, entre guillemets, un framework. Je ne connais pas un seul framework qui soit propriétaire, qui est tenu plus de quelques années. Je pense que ça n'existe pas. Et tous les CMS de l'époque qui étaient propriétaires il y avait beaucoup de CMS à l'époque qui étaient propriétaires ils n'existent plus aujourd'hui et il y avait des gros il y avait des gens qui faisaient beaucoup de chiffre d'affaires ça n'existe plus, donc je pense que j'avais compris aussi que si on voulait dépasser les frontières de la France d'un point de vue purement commercial et business il fallait quelque chose qui scale quelque chose qui désolé pour les anxieux, qui ne soit pas juste franco-français d'ailleurs on n'a jamais dit qu'on était français au début. Et tant que je ne parlais pas en anglais on pouvait faire illusion quelque part, non ceci étant dit même 5, 6 ans, 10 ans après la sortie de Symfony Open Source, il y a plein de gens qui me disent ah mais en fait c'est français et les gens ne savaient pas que c'était français on avait tout fait en anglais contrairement à N-moi, Spip, un CMS de l'époque oui malheureusement je vous donne plein d'indices pour vous dire que je suis vraiment vieux, Spip était quelque chose d'assez extraordinaire à l'époque, très révolutionnaire d'ailleurs, mais en français et même à l'intérieur c'était boucle donc c'était vraiment des mots en français donc c'était réduit à rester quelque chose de confidentiel et de franco-français moi je voulais quelque chose qui soit vraiment international, et l'open source c'est l'un des moyens, faciles et peu chers de pouvoir évangéliser une très large population. Bon commercialement Sensu est resté très franco-français au final mais en tout cas c'était l'idée donc l'idée 1 de partager C'est-à-dire que tout ce que j'ai appris, je l'ai appris via l'open source, en fait. Parce que j'ai lu de l'open source. Et donc, c'est aussi ma façon de redonner quelque chose, de dire, ben voilà, peut-être que modestement, j'ai amélioré ce qui existait avant moi. Allez-y. Améliorez ce que j'ai fait et faites autre chose qui est mieux ou différente. Et l'une de mes réussites, c'est la Ravel, en fait. Les gens me posent toujours la question, mais Symfony, c'est mort, maintenant, il y a la Ravel. Bon. J'ai plein de réponses par rapport à ça, mais la première réponse, c'est déjà, on est dans le même bateau. On est dans le bateau PHP. Donc, à la fois, on s'adresse à la même communauté, mais la compétition de Symfony, c'est peut-être Rubion Rail, c'est peut-être Django, c'est peut-être Spring. Est-ce que c'est Laravel ? Le monde, il est énorme. Le monde PHP, il est énorme. Donc, il y a de la place pour deux, trois, quatre, cinq frameworks. La réalité, c'est qu'on est quatre et demi, quoi. Donc, il y a de la place pour tout le monde. Et en plus, Laravel utilise Symfony. Donc, bon, l'un dans l'autre, c'est pas très grave. Mais Taylor il a fait un truc extraordinaire que malheureusement j'ai jamais réussi à faire c'est de le côté marketing il a marketé son framework de façon incroyable donc ce qu'il a fait c'est génial et il a pu le faire grâce à Symfony, parce qu'en fait il a construit au dessus de Symfony quelque chose qui est différent je l'aurais jamais fait comme ça c'est différent. Et je suis content je suis content il y a autre chose l'open source c'est un moyen extraordinaire de rencontrer des gens. J'ai rencontré un nombre de personnes incroyables que je n'aurais jamais pu rencontrer si je n'avais pas mis Symfony en open source. Je peux parler longtemps là-dessus. Donc, en fait, c'est à la fois une chance commerciale qu'on a eue pour Sensio et à la fois un désir profond de partager. J'ai été prof au début de ma carrière. J'étais un peu prof dans des écoles où je partageais, un, ma passion de l'entrepreneuriat, deux, ma passion de l'open source et du code en règle générale. Et je pense c'est ce qui m'a animé aussi quand je l'ai mis en open source de me dire en fait il y a une opportunité de partage, et de transmission du savoir maintenant si tu m'avais dit à l'époque que j'en serais là aujourd'hui je t'aurais dit mais non arrête non non impossible donc j'avais pas, l'ambition de dire il faut que ça devienne énorme que ça soit gros que ça soit le plus gros en PHP ou que je devienne c'est l'air c'était pas du tout ça c'était vraiment le partage.

Bruno:
Je te rejoins sur cette notion de partage parce que tu vois vu le contexte où je suis aussi dans cette démarche de partage, pas sur les mêmes aspects, mais tu l'as évoqué un petit peu aussi en début d'épisode, sur la qualité de ce qui est partagé dans un monde open source, là tu viens de redire ce côté qu'on n'a jamais forcément envisagé au début en tout cas que Symfony devienne le mastodonte que c'est aujourd'hui. Malgré tout, moi, quand je discute avec des développeurs ou des développeuses autour de moi, j'essaie de leur dire, contribuez à de l'open source, allez faire des trucs, et parfois sur podcast, on a reçu des gens pour essayer aussi de passer à ce message. Il y a quand même un truc qui reste, c'est qu'il y a une espèce de stress, en fait, de participer à ça, parce que effectivement, quand tu vois un projet comme Symfony, tu vois quand même la minutie, l'orfèvrerie que c'est, que c'est un niveau de développement et de qualité qui est absolument absolument, absolument Guedin. Et du coup, tous les développeurs et développeuses ne se sentent pas, enfin, ont l'impression que c'est pas un monde qui est accessible, tu vois.

Fabien:
La barrière à l'entrée, elle est de plus en plus grande. C'est évident.

Bruno:
Mais tu vois, est-ce que même toi, en 2005, quand t'as lancé ça, est-ce que t'avais l'impression que tu lançais un projet qui était qualitatif par rapport à ce qui se faisait dans le monde de l'open source à l'époque, où tu avais déjà le sentiment que tu faisais un truc top, ou est-ce que pour toi, c'était un petit projet parmi des millions de projets qui, en fait, sont sympas, mais pas ouf.

Fabien:
Les deux, mon capitaine. C'est-à-dire qu'à la fois, je suis ingénieur à la base, pas informatique, mais avec l'état d'esprit ingénieur comme on peut l'avoir à la française. Et donc, de faire quelque chose qui est carré, qui, d'un point de vue purement intellectuel, fonctionne bien, qui a un sens. Donc, je pense que j'avais quand même ce souci-là, de ce détail-là, de proposer quelque chose de solide, pas de révolutionnaire, parce qu'encore une fois, je me suis basé sur des choses qui existaient déjà. Et à la fois, j'avais un peu honte, quand même, du truc qui n'est pas parfait, mais de me dire, ok, je me lance, j'y vais, et puis on verra bien, et puis on va s'améliorer, et puis on va apprendre tous ensemble.

Bruno:
Donc ça veut dire que t'avais aussi ce sentiment, effectivement, de honte, je crois que t'as bien choisi le mot, c'est-à-dire qu'effectivement, il y a des gens qui se disent je ne peux pas mettre sur GitHub mon repo parce que j'ai honte de la qualité de ce que je produis.

Fabien:
Oui, mais ce n'est pas grave. Ce n'est pas grave. En fait, le but de l'open source, quand on dit partage, c'est partage dans tous les sens du terme. Et tous les projets open source n'ont pas vocation à devenir incontournable sur le marché. Mais ce n'est pas grave. C'est aussi un acte de... Moi, quand je vois des gens en entretien, le fait que les gens aient mis des choses en open source, ça veut dire aussi que je peux aller les voir. Donc, je peux aller regarder ce que les gens font, ce qui est aussi intéressant. Et même si c'est quelque chose de petit ou qui est un truc de niche ou qui n'a qu'un seul usage pour la personne qui l'a... Ce n'est pas très grave. Je ne trouve pas ça très grave. C'est aussi une façon d'apprendre à utiliser GitHub, à... C'est aussi une façon de se forcer. Ça, c'est un truc super important. De temps en temps, je veux régler un problème. J'écris un bout de code, une librairie, un truc. Et je sais que si je ne le mets pas en open source, je ne vais pas vraiment le maintenir. Je ne vais pas faire le. Dernier mile. Le truc qui fait qu'il y a un peu des tests, il y a un peu de la documentation. Je fixe un peu le nommage ou les trucs comme ça. Je réfléchis un tout petit peu plus et du coup deux ans après je suis là et le code ah merde où est-ce qu'il est je l'ai pas mis à jour jamais et donc globalement tout ce que je fais je le mets en open source à un moment ou à un autre et à chaque fois qu'il y a des trucs je me suis dit non non non ça je le garde pour moi c'est propriétaire, c'est toujours passé à un moment donné je dis ah c'est vraiment une connerie mets-le en open source évidemment qu'il faut que ce soit en open source tu t'en fous et en fait la valeur elle est pas dans le code et la valeur et un projet open source ce n'est pas le code jamais en aucun cas, c'est hyper facile pour n'importe qui de prendre du code de dire ah il est open source juste parce que bam on a mis un tampon GPL MIT BSD et on l'a mis quelque part sur GitHub, ça ça vaut rien c'est pas ça l'open source l'open source il n'a de valeur que s'il y a du partage que s'il y a une communauté, pas de communauté globalement pas d'open source. Après sur j'ai honte le syndrome de l'imposteur je l'ai aujourd'hui je l'ai et j'ai envie de dire plus je vieillis plus je l'ai parce que plus je vieillis plus j'en sais et plus je sais que je ne sais rien enfin c'est le truc classique mais, c'est peut-être une tarte à la crème mais je le vis vraiment et les gens sont mais non Fabien évidemment que tu ne l'as pas évidemment que je l'ai évidemment que je l'ai je suis nul en javascript et puis aujourd'hui honnêtement moi quand j'ai commencé en 98 un bout de perle un bout de ma SQL, un peu d'HTML ça.

Bruno:
Te faisait un site qui tournait très bien.

Fabien:
Terminé, c'est tout aujourd'hui la barrière à l'entrée, elle est juste, et du coup ouais, non, il faut commencer quelque part juste peut-être pour les contributions, une bonne communauté j'espère que c'est le cas chez Symfony, j'espère vraiment que c'est le cas sur Symfony, on n'est pas là pour juger jamais on est là pour trouver des solutions à des problèmes on est là pour fixer un bug on est là pour ajouter une fonctionnalité en fonction de besoins réels, et en fait les contributeurs globalement c'est des gens qui utilisent le framework et qui à un moment donné ont eu un problème, ils ont eu un bug et ils ont eu un bug parce qu'ils ont utilisé le framework donc c'est valide, ils ont besoin d'une nouvelle fonctionnalité parce qu'ils ont un besoin réel dans la vraie vie, Symfony d'ailleurs n'a évolué que comme ça je pense que c'est aussi une raison du succès de Symfony c'est que ça a réglé des vrais problèmes pour des vrais gens qu'il y avait des vrais projets dans la vraie vie. Et pas juste comme ça, tiens, je vais faire un framework. Non, ça sert à rien ça. Et donc, si les gens ont un problème, déjà, ils peuvent le reporter. Déjà, une issue. Facile à faire, ça n'engage à rien. Mais c'est déjà une première étape. La deuxième étape, c'est éventuellement, si on a compris le problème, d'essayer de le fixer. On ouvre une pull request sur GitHub, on propose une solution. Peut-être c'est la bonne, peut-être c'est pas la bonne. Si c'est pas la bonne on est là pour aider le problème majeur qu'on voit en fait c'est de dire ok t'as fixé le problème mais t'as pas fixé la cause réelle du problème et en fait ce qu'on veut fixer c'est la cause réelle parce que si on fixe pas la cause réelle dans 3, 4, 5 ans en fait on peut tout mettre à la poubelle, donc faut toujours trouver la route cause du problème c'est pas grave parce qu'on va essayer de t'aiguiller, on va essayer de t'aider et en fait globalement tu vas apprendre et on va apprendre et tout le monde va apprendre ensemble, c'est hyper dur parce que ça prend énormément de temps donc peut-être que ton temps on le fait pas bien mais en tout cas c'est vraiment le but et l'accord team de Symfony c'est ce que j'essaye de leur dire aussi c'est ce que j'essaye de leur inculquer de dire on n'est pas là pour juger on n'est pas là pour dire, c'est vraiment débile ton code t'es vraiment nul non non c'est pas intéressant on est tous nuls et on est tous là pour, essayer d'améliorer choses et trouver les meilleures solutions ouais.

Bruno:
Sur ce que t'as dit il y a plusieurs éléments sur lesquels ça me donne envie de rebondir le premier c'est que, Bon, déjà, je ne sais même pas si ça vaut le coup de poser la question de dire, est-ce que Symfony aurait pu en être là où ça en est aujourd'hui sans l'open source ? Parce que j'ai eu le nombre de personnes qui ont contribué au projet.

Fabien:
Non, à penser non.

Bruno:
Clairement, ça, je suis entièrement d'accord. Et je ne vois même pas comment est-ce que tu pourrais réussir à imaginer une entreprise qui aurait réussi à arriver à ce niveau de qualité. Parce qu'en fait, le nombre d'ingénieurs qu'il faut réussir à driver sur ce truc-là, ce serait absolument hallucinant. Mais c'est ça en fait que je trouve assez fascinant. Et ce n'est pas que les gros projets open source, c'est le cas aussi de beaucoup de projets open source. Moi, j'ai participé aussi à pas mal de start-up, mais à pas mal de boîtes. Et il y a toujours un problème permanent dans les boîtes, c'est que la code base n'est pas suffisamment testée, qu'il n'y a pas suffisamment de documentation, que la nomenclature n'est pas toujours respectée, que le code n'est pas forcément parfaitement clean. Et pourtant quand tu regardes des projets open source où personne n'est payé pour que ça fonctionne on a des projets où il y a une code coverage qui est hyper bonne, il y a de la documentation les nomenclatures sont respectées, est-ce que ça nous ferait croire que si on disait dans une entreprise on va mettre aucune règle tu vois que le chaos finirait forcément par s'organiser de lui-même peut-être.

Fabien:
J'y crois pas tellement parce qu'en entreprise il y a des vraies contraintes, de budget, de délai le nombre de personnes qui peuvent contribuer, de capacité à délivrer tout le monde n'a pas le même niveau tu vois donc il y a beaucoup beaucoup de contraintes qu'il faut prendre en compte l'open source, t'as le temps de travailler super t'as pas le temps de travailler ce mois-ci pas grave on est 25 ou 26 membres de l'accord team dans Symfony, quand il y a des nouveaux membres qui arrivent, leur première question qu'ils me posent, c'est de dire, c'est quoi l'investissement que je dois faire ? Zéro. Tu ne dois rien. Tu ne dois rien à personne. Tu veux passer tous tes week-ends pendant un mois ? Génial. Tu ne veux plus rien faire pendant six mois ? Ça marche aussi. Il n'y a aucune contrainte. Et je pense que c'est super important parce que ça veut dire que les gens, et moi, ça m'arrive, de temps en temps, je n'ai pas envie. Mais je n'ai pas envie du tout. Je ne suis pas dans ce mindset-là. J'ai la chance d'avoir un métier qui est à la fois technique et puis à la fois je suis manager et je gère des entreprises et donc du coup je peux switcher de l'un à l'autre mais de temps en temps pendant 2-3 semaines je veux pas faire de code parce que j'ai pas le bon mindset donc je fais pas et puis tout d'un coup on sait pas pourquoi, il y a une idée il y a quelque chose qui arrive et là tout d'un coup tout à fait c'est sort il faut prendre l'ordinateur et pendant 8h 10h d'affilée et ça tombe tout seul, ce qu'on peut pas faire en entreprise en tant que développeur on peut pas aller voir son patron et dire ah en fait là pendant 2 semaines je ne vais rien faire parce que je ne le sens pas.

Bruno:
Peut-être trois d'ailleurs.

Fabien:
Peut-être trois, on verra bien. Ça ne marche pas ça. Donc, il y a cette liberté-là, d'ailleurs free, free, free dans tous les sens du terme, et cette liberté-là en open source, elle est génératrice de qualité, je pense. Après, je pense aussi qu'il y a cette contrainte de dire si je mets en open source, il faut que je donne le meilleur de moi-même. De temps en temps, l'entreprise, bon, allez, on va prendre un raccourci. Ceci étant, c'est de la dette technique tout ce qu'on dit là c'est de la dette technique donc on va la payer à un moment ou à un autre et, ce qui est insupportable en entreprise c'est de dire ah ouais mais ce code là on peut plus le maintenir on va recommencer à zéro, toujours une mauvaise idée tout le monde le sait c'est une mauvaise idée mais on le fait et c'est juste parce qu'on n'a pas on n'a pas géré cette dette technique, et que sur un projet open source si on ne gère pas, au jour le jour la dette technique il y a un moment donné et bien on meurt on meurt parce que c'est plus maintenable et il n'y a plus personne qui a envie de toucher au code. Et s'il n'y a plus de contribution au code, le code est bon.

Bruno:
Donc, tu penses que ce côté d'avoir ton code qui est visible, qui est aux yeux de tous, ça te met une obligation de le faire dans les meilleurs états de l'art ?

Fabien:
Oui, et ça force aussi. Je prends un exemple, Twig, qui est le système de templating de Symfony, qui est mon projet préféré. C'est mon petit bébé. Il n'y a quasiment que moi qui contribue. Non, c'est intéressant parce qu'il y a plein de choses. Il y a un tokenizer, il y a un lexer, il y a un parseur, il y a un compiler. Il y a plein de choses intéressantes, donc j'apprends plein de choses en faisant ça. Et en fait, là, j'ai passé quelques mois à revoir des briques fondamentales de Twig. Est-ce qu'il y avait besoin ? La réponse est non. Est-ce que quelqu'un m'aurait payé pour faire ça ? La réponse est non. Est-ce que c'est bien pour le projet et le futur du projet ? La réponse est oui. Et c'est possible parce qu'à un moment donné, j'ai passé des soirs, j'ai passé des week-ends et que j'ai la chance aussi d'être un peu payé pour faire ça.

Bruno:
Mais tu vois, c'est marrant ce que tu dis. Est-ce que quelqu'un m'aurait payé pour ça ? Symfony est quand même énormément utilisé. C'est indéniable. Tweak, du coup, est aussi beaucoup utilisé. Il y a des débats sur Tweak ou pas, mais ça c'est un autre sujet moi moins parce que je suis moins dedans dans ces sujets là maintenant donc je me permettrai pas de l'avoir, et tu vois quand tu dis est-ce que quelqu'un serait prêt à me payer pour ça je suis sûr qu'il y a plein de boîtes qui seraient prêtes à te dire ok Fabien nous on a besoin de tel truc sur Twig on est prêt à mettre l'argent qu'il faut mais en fait c'est qu'effectivement ils vont te dire j'ai besoin de ça là où toi tu dis le fait Twig a pas besoin de ça Twig a besoin de la route cause en fait de corriger le truc.

Fabien:
Ouais c'est aussi le fait que depuis 10 ans ou 15 ans que je gère Twig, j'ai accumulé des choses, des problèmes qu'on ne peut pas régler et puis on ne sait pas comment les régler. Et puis à un moment donné, on se dit, ah, mais j'ai tout en tête et j'ai ça, ça, ça, ça et en fait, je pense que j'ai une idée qui permettrait de régler tout ça. Mais de temps en temps, il m'a fallu deux ans ou trois ans avant de me dire, ah ok, ça y est, j'ai compris. Comme Symfony 2, l'injection de dépendance. Ça n'existait pas en PHP. Ça n'existait en aucun langage dynamique, et d'ailleurs ça n'existe quasiment que en PHP à cause de moi peut-être, et en fait on était à une conférence mausuelle aux Etats-Unis et j'achète un bouquin Java, j'ai jamais fait Java de ma vie jamais, jamais, jamais, mais je suis hyper curieux j'adore les bouquins, on en parlera tout à l'heure et du coup j'achète beaucoup de livres des romans, des trucs techniques un peu moins techniques de nos jours parce que c'est moins en vogue mais à l'époque j'avais acheté un bouquin, sur Spring d'un auteur incroyable, et il y avait peut-être la moitié du bouquin sur l'injection de dépendance. Et j'étais en train de réfléchir à Symphonie 2. Et je lis le bouquin et je me dis, boah, poum, mind-blowing. Tout d'un coup, il y a un univers qui s'est ouvert. Je me suis dit, mais en fait, ça va nous régler plein de problèmes. Et ça a réglé plein de problèmes. Et c'est le fondement de Symphonie 2 qui fait que 15 ans après la sortie de Symphonie 2, il faudrait calculer, mais un truc comme ça, les fondements sont toujours là. Et il y a des trucs qui n'ont pas changé depuis 15 ans et qui ne changeront pas parce que fondamentalement, les fondations, c'était la bonne idée. C'est pas mon idée c'est une idée qui vient du monde Java.

Bruno:
Alors je te préviens d'emblée je vais faire un extrait vidéo de cette, partie là parce que pour moi c'est le fondement même de ce podcast c'est que c'est ce que je t'ai dit en préparation c'est que moi je suis convaincu que ce qui fait la différence avec un ou une bonne développeuse c'est avant tout une capacité à s'intéresser à autre chose que ça c'est à la quotidienne parce que justement quand tu vas voir ce qui se passe ailleurs tu te dis ah mais en fait peut-être que je pourrais réussir à creuser un truc Et tu vois, il y a un autre sujet que je n'ai pas encore réussi à craquer mais que je trouvais hyper intéressant. Dans le monde du jeu vidéo, ils ont une mécanique de ticker pour faire le refresh rate. Et de part aujourd'hui, la quantité d'éléments qui sont gérés par les jeux, ils ont une mécanique différente. Je ne me souviens plus le détail exact, mais en fait, cette mécanique de ticker avec les millions d'objets qui sont à gérer, fait que le transfert d'informations entre le ticker qui met à jour ce qui est visible à l'écran versus la position de tous les éléments, c'est un truc que je n'ai jamais réussi à trouver. Comment est-ce que je pourrais l'utiliser dans un projet web classique ? Mais je me dis là, il y a une philosophie, il y a une conception un peu différente. J'aimerais bien réussir à craquer un truc parce que je trouve ça hyper intéressant d'aller piocher sur ce qui se fait ailleurs pour faire un truc mieux de notre côté.

Fabien:
La curiosité de toute façon dans notre monde, elle est incroyable. Ce que je reproche un tout petit peu aïe aïe aïe je vais pas me faire des amis là ce que je reproche un tout petit peu au monde javascript, pas aujourd'hui mais il y a quelques années le monde javascript est parti de, un langage que tout le monde fuyait, au langage avec un grand L d'ailleurs il y a une espèce de thème là quand même personne aime le PHP mais tout le monde fait du PHP personne aimait le javascript tout le monde fait du javascript Go est un langage qui est hyper utilisé et quand on regarde Go, c'est pas un beau langage mais c'est un langage pragmatique et en fait, le truc commun entre PHP Go et JavaScript c'est que ce sont tous des langages pragmatiques, Et c'est ce qui me plaît, en fait. On a envie d'être... Moi, je ne fais pas du code pour la beauté du code, en fait. J'essaye de faire que ça soit le plus élégant possible, le mieux construit possible. Mais au final, ce qu'on veut, c'est trouver des solutions à des problèmes qu'ont nos clients ou qu'on a nous-mêmes. Et PHP fait le job. Honnêtement, aujourd'hui, pourquoi PHP est le populaire ? C'est que tu écris un bout de code en PHP, tu le mets n'importe où, sur n'importe quel hosteur, dans 15 ans, il tourne toujours. Et tu n'as pas besoin de le monitorer. Ce n'est pas un souci. Et la philosophie de Go en fait quand on regarde et qu'on lit un peu comment ils ont réfléchi au problème c'est le pragmatisme c'est pas de faire du code parce que, la théorie du code a vachement évolué il y a plein de langages qui sont très théoriques bon pourquoi pas Go c'est pas ça Go c'est pragmatisme et t'entends il y a des trucs ah c'est moche la gestion des erreurs en Go la première fois où on voit ça on se dit mais à quoi ils ont pensé c'est les erreurs comme elles existaient en PHP 4. Et ce que j'aime bien en Go, c'est que, en fait, il y a une justification. C'est-à-dire que quand tu regardes et tu creuses un peu, il y a une justification de pourquoi les erreurs sont faites de cette manière-là. Et ça, c'est super intéressant. En PHP, je ne sais pas pourquoi ils ont fait ces erreurs-là à l'époque et pourquoi on a basculé sur des exceptions. Pas clair. En Go, on sait et on peut lire. Il y a vraiment un rationnel derrière. Hyper intéressant. Et je pense qu'effectivement, la curiosité d'un développeur... D'ailleurs, on le sait, Je disais tout à l'heure, je passe des soirs et des week-ends encore à coder, parce qu'en fait, je pense que fondamentalement, un développeur, s'il ne code pas en dehors de ses obligations quotidiennes de travailler sur des projets, c'est compliqué. C'est compliqué de rester à jour en fait et de monter en compétence. Ou sinon sinon sinon sinon ça c'est la Silicon Valley, sinon ce qui se passe c'est qu'on a des startups qui lèvent beaucoup d'argent qui doivent embaucher énormément de monde, et ils essayent d'attirer les gens et pour attirer qu'est-ce qu'ils font ils disent ah bah nous en fait on utilise le dernier framework à la mode en javascript et tout le monde est là waouh waouh je veux apprendre et c'est là où il y a le problème je veux apprendre ce nouveau framework parce qu'il est hype et donc je vais poser celui-là et donc on se retrouve avec des boîtes et j'en ai, plein en tête, qui font ça qui donc recrutent énormément de gens, qui payent très cher, parce que c'est un nouveau framework, il est hype donc forcément les gens ils sont très chers, mais les gens en fait ils n'y connaissent rien puisque le projet il est nouveau il vient de sortir, mais il est hype, ils développent quelque chose, au bout de 6 mois 1 an, bah évidemment les best practices n'existent pas, et puis le code il est pourri, et le mec au bout d'un an bah en fait il y a une nouvelle technologie qui hype puis en plus le code là il est pas bon il y a plein de dettes techniques on n'arrive plus à faire le truc qu'est-ce qu'ils font ? ils se barrent la boîte d'après. Je ne suis pas hyper fan de ça. Ce que j'aime bien dans le monde PHP, ce que j'aime bien dans le monde Symfony, ou dans le monde Java, ou dans le monde maintenant Ruby on Rails, il y a quand même des langages qui sont très matures aujourd'hui et des frameworks qui sont hyper matures, c'est qu'il y a une stabilité. Et je pense que quelque chose qui est hyper important aussi, que j'aime bien et que j'essaye de maintenir dans Symfony, c'est une stabilité. Et les gens, ils choisissent Symfony aussi parce qu'il y a une stabilité. On a deux releases par an, fin mai, fin novembre, tout le monde le sait une LTS tous les deux ans et c'est le cas depuis 10 ans, 15 ans on n'a jamais loupé une release, tous les mois des release patchs une backwork compatibilité, on la connait on connait les règles, on sait ce qu'on fait, ce qu'on fait pas et je pense que ça, notamment dans un usage entreprise.

Bruno:
C'est fondamental fondamental, Tu as évoqué le sujet de JavaScript effectivement est intéressant, parce que c'est vrai qu'il y a aussi une montée en gamme de JavaScript qui effectivement il y a, moi j'ai commencé aussi à coder assez tôt et je suis arrivé dans ce monde là aussi début des années 2000, à l'époque effectivement j'avais script c'était une catastrophe on voulait pas, on évitait et petit à petit effectivement ça s'est quand même hyper professionnalisé et puis surtout extrêmement, complexifié, t'en as parlé aussi tu parles tout à l'heure de la barrière à l'entrée qui a beaucoup augmenté, est-ce que je vais te poser la question de manière un peu provocante volontairement. Est-ce que tu as conscience de la contribution que tu as eue, toi, au travail de Symfony, sur la complexification du dev web en général ?

Fabien:
Je m'explique.

Bruno:
Je m'explique un peu la question. Parce qu'en fait, au final, d'une certaine manière, avec Symfony, t'as baissé de la barrière à l'entrée. T'as rendu... Comme tu le disais, tu peux faire un bout de code en PHP, tu le mets sur un site et ça fonctionne.

Fabien:
Mais tu ne maintiens pas.

Bruno:
Mais tu ne maintiens pas et il ne fera pas grand-chose. Aujourd'hui, avec Symfony, t'embarques tout un ensemble de logiques et de capacités où tu peux faire beaucoup plus facilement ta gestion de tes sessions, de tes droits d'accès, de tout un tas de choses qui te demanderaient énormément de travail. Donc, t'as baissé la barrière à l'entrée. Donc, tu permets à des gens de faire des choses beaucoup plus compliquées, beaucoup plus facilement. Mais du coup, au final, on fait des choses beaucoup plus compliquées qu'avant.

Fabien:
Ouais, des choses plus maintenables, plus sécurisées, plus etc. Je peux pas te donner tort, Ceci étant, si on regarde ce qu'on a fait sur Symfony depuis les 5-6 dernières années, c'est d'essayer de simplifier. Il y a eu une phase, les premières années de Symfony 2, où petit à petit, on a créé les fondations, les briques fondamentales. En fait, je pense qu'on ne peut pas avoir une bonne expérience développeur si on n'a pas des fondations qui sont hyper solides. Donc à chaque fois que je crée un nouveau composant par exemple, j'essaie d'utiliser le composant en soi juste ce composant là, est-ce que ça marche ou pas parce qu'évidemment quand il est, complètement auto-configuré par Symfony par Framework Bundle ça marche, mais si je veux utiliser que ce composant là tout seul, ça marche ou est-ce que c'est trop compliqué, ou il y a trop de wiring à faire trop de config, etc, c'est hyper banteau pour moi, mais donc ça on le fait d'un point de vue fondamental et je pense que depuis 5-6 ans, on essaye de faire en sorte de simplifier au maximum la vie ? PHP nous aide aussi, avec notamment les attributs en PHP qui simplifient énormément les choses. Est-ce qu'on est arrivé ? Non. Mais est-ce que c'est beaucoup plus simple de faire du symphonie aujourd'hui qu'il y a cinq ans ? Oui.

Bruno:
Alors attention, je ne suis pas en train de dire que c'est devenu compliqué de faire du symphonie.

Fabien:
Moi, je le dis.

Bruno:
D'accord, mais moi, ce que je voulais dire, c'est que comme tu as simplifié beaucoup d'éléments, que tu as rendu le travail beaucoup plus simple sur plein de sujets, tu permets à des gens de faire des choses plus compliquées, parce que du coup, tu peux concentrer ton travail sur effectivement des choses qui ont plus de valeur ajoutée. Enfin, tu sais, on peut le tourner comme on veut. Mais que donc, en permettant à plein de gens de faire des choses plus complexes qu'avant, en fait, tu as contribué à rendre tous ces métiers-là plus complexes qu'avant. Parce qu'en fait, on fait des choses plus compliquées qu'avant.

Fabien:
Oui et non. Oui et non. Ah, j'avais plein d'idées en tête. Je ne les ai plus. J'en ai une qui m'est restée. Oui, plus compliquées, mais en fait, idéalement, j'aimerais bien que ce qui est simple reste simple et ce qui est compliqué reste possible. C'est un peu la philosophie de Symfony. Donc, tu fais des trucs simples, tu restes simple, mais si tu veux complexément, tu peux le faire. Tu peux descendre dans la stack et tu as complètement la liberté de faire tout ce que tu veux. Je pense qu'on n'est pas tombé dans un travers chez Symfony, c'est la multiplicité des services. Donc, si tu regardes la documentation de Symfony aujourd'hui et le bouquin que j'ai écrit sur Symfony. En fait il y a quelques années on utilisait PHP, PostgreSQL RabbitMQ Redis en tout cas on essayait d'introduire tout ça et tout d'un coup je me suis dit mais en fait on peut tout faire avec PostgreSQL et donc je suis un avocat et un fervent défenseur de dire dans 99% des projets, Symfony plus PostgreSQL, ça suffit. Ou n'importe quoi, peu importe, et PostgreSQL, ça suffit. Et aujourd'hui, on regarde le web et les technologies web par un prisme qui n'est pas bon, en fait. Par le prisme des Google, des Netflix, en fait, des cafames. Et en fait, le problème, c'est que les problèmes que eux ont à résoudre, on ne les aura jamais. ce.

Bruno:
Sont les seuls à avoir ces problèmes là.

Fabien:
C'est les seuls et le nombre de projets qui nécessitent d'avoir plus que juste, un truc PHP, JavaScript, peu importe et pause resql il est minusculissime, combien d'histoires de gens qui ont commencé à mettre du Redis, du RabbitMQ du Cassandra il y en a plein plein plein du MongoDB, du Bidu et du Chouette.

Bruno:
Qui cherchent Day One à être capable d'engranger un million de clients simultanés.

Fabien:
Exactement.

Bruno:
Alors qu'il n'y en a même pas un.

Fabien:
Exactement. Et peut-être au final, malheureusement, il n'y en aura jamais plus que quelques centaines ou quelques milliers ou quelques dizaines de milliers. Et donc, on règle des problèmes qu'on n'a pas. Je ne sais pas si j'ai envie de dire ça, mais... Microservices. Je n'y ai jamais cru. Jamais, jamais, jamais. Je n'ai jamais compris. Découplage, ça je comprends. Microservices, je ne comprends pas. Et là, les gens se sont imposés une complexité qui n'était pas nécessaire. Et probablement qu'à l'échelle de Google, une architecture en microservices, oui, 100%, ils en ont besoin et ils n'ont pas le choix. Mais ce qu'on ne comprend pas forcément quand on dit microservice, c'est tout ce que ça entraîne derrière de nouvelles problématiques que tu n'as pas si tu as une machine avec une base de données, éventuellement sur la même machine. Et dès qu'on a du microservice, oui, mais du coup, on peut redonder, etc. Gut feeling, c'est qu'en termes de uptime, quand tu es en microservice, c'est beaucoup plus difficile d'avoir un 4.9 qu'avec une machine.

Bruno:
Avec tout dessus alors ce que je trouve amusant c'est que il y a quelques temps on avait reçu Grégoire de Grégoire Pinot que tu connais bien effectivement qui était venu parler de Symfony, et qui avait eu alors il me semble que c'est lui qui avait eu des propos similaires sur les microservices et qui avait donné une phrase que j'avais trouvé très juste et qui restait avec moi c'est que le microservice ça répond plus à une, problématique d'équipe qu'une problématique technique. C'est-à-dire qu'en fait, si tu as des problèmes effectivement de gestion d'une code base qui est énorme, que tu as une équipe qui est colossale et compagnie, ça peut être intéressant de faire du microservice pour des questions d'équipe, mais pas pour des questions purement techniques.

Fabien:
Les microservices, en fait, le seul intérêt, c'est les interfaces. Donc, le seul truc qui m'intéresse dans les microservices, c'est quelles sont les interfaces entre les différents microservices. Si les interfaces ne sont pas très bien définies, ça marche pas ça rejoint un peu ce que dit Grégoire c'est-à-dire qu'une interface c'est effectivement une équipe une équipe qui délivre quelque chose et donc qui expose au monde une interface je dis interface, je dis pas forcément API donc une interface, peu importe ce que c'est, si cette interface là elle est bien définie, paiement authentication whatever, alors oui ça peut avoir un intérêt mais c'est extrêmement compliqué de pouvoir définir des interfaces qui marchent bien, c'est très très compliquée. Et si au final t'es pas capable de définir ces interfaces, ou qu'elles deviennent, liquides, c'est bien pire que d'avoir un monolithe. Dans Symfony, on a toujours d'ailleurs la notion de bundle. C'est plugin, add-on, peu importe. D'un point de vue open source, on comprend. C'est-à-dire, je développe un module, un bundle, peu importe, et je le contribue en open source pour que les autres puissent en profiter. OK, ça, je comprends. Et après, les gens se sont posés la question, mais quand moi, je développe pour ma société un produit, est-ce que je dois faire des bundles ? Un bundle ou plusieurs bundles ? Les gens ont tendance à dire, bah oui, je vais faire plusieurs bundles. Alors, je vais faire un bundle user management ou un bundle sécurité ou un bundle blog ou un bundle CMS. Et quand je faisais du code review et que je regardais un peu le code des autres, en fait, s'il y a une interface qui est très claire, si on va réutiliser le bundle, le module, la donne, mais si au final, il y a un peu de tout, un peu partout, pas la peine. C'est pire que mieux. C'est la difficulté de notre métier. C'est où est-ce qu'on met l'abstraction ? Quand est-ce qu'on abstrait ? Quand est-ce qu'on n'abstrait pas ? Et surtout, en tant que Français, en tant qu'ingénieur, on a plutôt cette mentalité de dire on va faire une abstraction au cas où généralement c'est une mauvaise idée, et un peu de copier-coller ça marche, c'est pas grave c'est pas très grave surtout qu'on a plein d'outils maintenant pour les détecter pour les gérer, donc c'est pas vraiment un problème, et de temps en temps aussi quand on parle d'équipe, quand on parle d'interface on essaye de régler par le code des problèmes organisationnels jamais une bonne idée, Il n'y a jamais rien qui remplace de la communication entre les gens plutôt que de mettre une interface technique au milieu.

Bruno:
Et puis, il y a aussi la loi de Conway qui montre qu'en général, le code est le reflet de l'organisation. Et tu ne peux pas changer l'organisation en changeant le code. Il faut changer l'organisation si tu veux changer le code.

Fabien:
Complètement, je suis d'accord. Et aussi, ce qu'il faut comprendre, c'est que la complexité, ce n'est pas linéaire. C'est exponentiel. Donc, la complexité, il y a un moment donné où hop, out of control, c'est fini, terminé. Et une fois que c'est parti, c'est fini. Tu ne peux plus revenir en arrière.

Bruno:
Pour revenir au sujet d'origine de cet épisode, qui est de parler du monde de l'open source, qu'est-ce que tu as vu, toi, comme évolution, si tant est qu'il y en ait une, de la philosophie ou du monde open source sur ces presque 30 ans maintenant ?

Fabien:
Le monde de l'open source a énormément évolué. Un, parce que c'était très confidentiel. Il y avait très peu de projets open source où c'était très... Si, évidemment, en Perle, si on regarde en 98, il y avait peut-être 10 000 librés qui étaient en open source, mais c'est des petites choses. Mais des projets qui comptent en open source, il y en avait assez peu. Aujourd'hui, tout le monde fait de l'open source. J'ai même envie de dire une société qui ne fait pas d'open source. T'es bizarre, toi. Et on est passé d'un monde où on était de l'open source communautaire, et on faisait ça quasiment pour la beauté de l'art, et c'était quasiment désintéressé, à un monde où l'open source aujourd'hui, il est très commercial, il est très marketing. Et on en a parlé un peu quand on a préparé, mais surtout dans un podcast en français, en France, pour moi, c'est vraiment l'open source de gauche, l'open source de droite. Généralement, les gens, ils captent ça. Malheureusement, je me suis trompé à l'origine et j'ai fait de l'open source de gauche. Open source de gauche, c'est quoi ? C'est, on donne un truc, on essaye de faire évoluer. Les bonnes pratiques, de comment on fait pour développer du code, et on le fait tous ensemble, sans arrière-pensée, même si, attention, au final, évidemment qu'il y avait une arrière-pensée commerciale et marketing. Symfony, j'ai l'habitude de dire, ça a toujours été notre meilleur commercial, au final. Évidemment qu'il y avait cette arrière-pensée-là, mais en tout cas, quand j'étais dans mon mindset Symfony, j'étais dans un mindset open source. Et qu'est-ce qui est bien, comme décision pour le projet open source. Même si ça peut être une mauvaise décision, en tout cas pas une décision idéale pour la société Sensua. Hyper important. L'open source de droite, c'est l'open source comme étant un alibi. Comme étant un alibi commercial, un alibi marketing, un élément marketing comme on peut écrire des blog posts sur tout et n'importe quoi pour essayer d'attirer le chaland ou comme avoir une stratégie SEO ou dire « Ah tiens, on va mettre ça en open source, comme ça, on aura des contributeurs gratuitement. » Non, ça, ça ne marche pas. Ça, ça n'existe pas. Ce qui est le plus dur dans un projet open source c'est de construire une communauté ça c'est des années de travail, on parle toujours du overnight success le truc n'était pas connu tout d'un coup il est connu mais en fait généralement le overnight success c'est 10 ans c'est juste que tu n'avais pas vu tout le travail qu'il y avait avant et puis tout d'un coup il devient célèbre mais ouais non en fait il y a eu beaucoup de travail. Et je reste convaincu qu'en fait au final c'était une bonne idée de faire de l'open source de gauche parce que cet aspect transmission pour moi il est super important et je suis hyper fier de ça, en fait. Je suis beaucoup plus fier de la réussite de Symfony que de la réussite de mes sociétés qui, au final, moi, je n'ai jamais créé de start-up machin où on a levé des millions et j'ai fait des milliards. Heureusement, malheureusement, je n'en sais rien. Mais en tout cas, je n'étais pas dans ce délire-là. Par contre, ce qui me gêne beaucoup, c'est la récupération du mouvement open source au sens noble du terme pour des entreprises purement commerciales qui s'en foutent complètement de l'aspect communautaire. C'est pour se donner une bonne conscience, peut-être. Et après, il y a un open source de... Un peu l'obligation de se dire bon bah mes clients me le demandent c'est-à-dire ils ont envie d'avoir de la visibilité donc je le mets en open source pour au cas où demain bah je dépose le bilan ok le code il est quelque part avec une licence open source donc bon ça pourquoi pas mais c'est pas de l'open source c'est juste, une assurance pour les clients et c'est complètement différent, d'ailleurs on le voit il y a des projets open source je vais pas dire plein mais il y a des projets open source qui ont beaucoup de contributeurs mais quand tu grattes un peu en fait tu te rends compte que c'est que des salariés, d'une entreprise ou de quelques entreprises et s'il n'y a pas ce que je disais tout à l'heure cette flamme, cette envie d'améliorer les choses pour améliorer les choses sans arrière-pensée, on perd quelque chose de l'open source. On perd vraiment quelque chose.

Bruno:
Comme sur le troisième point que je souhaitais évoquer sur l'impact des LLM, je suis conscient qu'il y a des projets d'IA et de différents modèles qui sont en mode open source, donc ça, très bien.

Fabien:
On pourra en reparler de qu'est-ce que ça veut dire ?

Bruno:
On est entièrement d'accord. Mais est-ce que pour toi, justement, le fait qu'on a un métier de dev qui est en train de changer, mine de rien, avec ces outils-là, est-ce que tu penses que ça va d'une certaine manière, de la même manière que ça a impacté l'audience de Stack Overflow, Est-ce que tu penses que ça peut impacter le monde de l'open source ?

Fabien:
J'en suis intimement persuadé. Intimement persuadé. Hum... C'est une révolution incroyable. Et on a un âge, je ne vais pas me mettre tout seul, mais on a un âge, en fait, on a eu une chance extraordinaire. On est arrivé quand le web était encore petit, donc on a pu apprendre. Parce qu'en 98, 99, 2000, on savait tout sur tout, en fait. C'était facile de connaître tout, en fait. Jusqu'à ce qu'on appelle maintenant DevOps, en fait. On déployait, en machin, on faisait tout, ce n'était pas un problème.

Bruno:
Parce que ce que les jeunes d'aujourd'hui ne réalisent peut-être pas, c'est que fin des années 90, tu pouvais héberger un site accessible au monde entier, sur ton PC, chez toi, derrière une connexion de ADSL bête et méchante, et ça fonctionnait très bien. C'était fine, en fait, par rapport au reste du monde.

Fabien:
Ouais, complètement. Et l'autre chance qu'on a eue, c'est que on a appris au fur et à mesure. Au fur et à mesure qu'il y a eu cette complexité, qu'il y a eu de plus en plus de projets open source, de plus en plus de trucs à faire. On a appris sur le tas, en fait. Moi, j'ai appris sur le tas. Donc, la complexité, je ne l'ai jamais vue, parce que j'ai accumulé du savoir au fur et à mesure. Donc, c'est une chance incroyable. Et honnêtement, aujourd'hui, oui, la barrière à l'entrée, elle est énorme. Elle est vraiment énorme. Je pense que la marge qu'il ne faut pas louper aujourd'hui, c'est ça. C'est l'LLM. Enfin, pas LLM, d'ailleurs. AI, en règle générale. Ce n'est pas nouveau. Moi, durant mes études, j'en ai fait. Donc, ce n'est pas nouveau. Ce qui est nouveau c'est l'accès à la data, c'est la puissance de calcul tout ça c'est nouveau et donc du coup ça permet de faire beaucoup plus de choses que ce qu'on faisait à l'époque mais reconnaître des chiffres écrits à la main, ça je l'ai fait quand j'étais à l'école, donc ça existait déjà. C'est aussi un piège je l'utilise tous les jours aujourd'hui j'utilise tous les jours mais je pense que j'en tire un gros avantage parce que je pourrais le faire moi-même, en fait. Je peux revenir au premier truc, je suis paresseux, comme tout le monde, et de temps en temps, t'as un syndrome de la page blanche. Tu sais, comme quand t'écris un bouquin, j'en ai écrit plusieurs, par où je commence, ou t'écris une lettre à quelqu'un, ou tu sais pas par où commencer, ou un email, ou je sais pas quoi. Et de temps en temps, quand t'écris du code, tu sais que ça va être vraiment compliqué, t'en as pour des semaines, et t'as pas envie de commencer, t'es là, j'ai pas envie. Le LLM, lui, il s'en fout. Il s'en fout. Il n'a pas cette notion de temps, il n'a pas cette notion d'effort ou quoi que ce soit. Donc, c'est un super assistant de ce point de vue-là. Je pose plein de questions. Est-ce qu'un LLM écrit beaucoup de codes pour moi ? Pas vraiment, en fait. Je m'en fous un peu. Mais il me débloque les situations. Ah, j'ai fait un truc, tiens, pour Twig. J'ai fait un playground où tu peux utiliser Twig directement dans le navigateur. Donc, en WASM, avec du PHP qu'ils exécutent directement dans le navigateur. Autant te dire qu'avec mon niveau de JavaScript, waouh, tu vois... J'ai fait ce projet en, je ne sais pas, j'ai mis deux jours peut-être, tout compris, mais j'ai pu le faire parce que j'avais quelqu'un qui m'aidait en fait. Donc la partie WASM, tout ça, je me suis démerdé. Mais après, la partie JavaScript, même la partie design, je suis nul en design. Ça me gonfle, mais je suis nul. Je vois des sites et je me dis c'est super simple à faire, puis j'essaie de le faire mais non c'est super moche, c'est quoi la différence ? En fait c'est quelques pixels, quelques machins et le LLM il a cette capacité de, je vais te faire le design qui va bien, et boum boum et en deux jours j'ai fait le truc et j'étais hyper content, et à la fois je me disais, mais si j'avais pas tout le background et tout le savoir que j'ai, ça aurait été hyper compliqué, parce que de temps en temps je dis, non non, attends Coco t'es gentil, mais là non, non, non, non, là c'est trop de sécurité là ça va pas marcher, là t'es en train de me faire n'importe quoi. Donc, j'ai cette capacité d'être critique par rapport à ce qu'il fait, de prendre des choses et d'en laisser. Et ma grande crainte, c'est que on ait des gens qui, du coup, ne fassent plus l'effort, en fait, d'apprendre les fondamentaux et d'avoir des gens qui sont capables d'utiliser des outils mais qui ne les maîtrisent pas complètement, qui ne comprennent pas exactement ce qu'ils sont en train de faire. Et donc, on crée une génération de développeurs qui sont un peu. L'humain qui aide les AI et pas l'humain qui drive les AI en fait. Des gens qui ne sont pas, qui ne contrôlent pas en fait. Un truc qu'on disait dans le temps, est-ce que vous devez créer votre propre framework ? La réponse est oui. Est-ce qu'il faudra le mettre en open source ? La réponse est peut-être oui. Est-ce qu'il faut qu'il soit populaire ? La réponse est non. Est-ce que vous allez le mettre à la poubelle ? La réponse est oui. Mais d'un point de vue apprentissage, Le fait de créer son propre framework et donc de comprendre la mécanique et comment ça marche et quels sont les problèmes et comment on les résout. 100%. Le truc du LLM, c'est pareil. Il faut faire des choses qui sont difficiles. Il faut passer par des moments où tu ne comprends pas, tu ne sais pas comment tu vas y arriver, parce que c'est comme ça que tu apprends et c'est comme ça que tu acquires de l'expérience. Est-ce qu'on peut être un senior développeur après deux ans d'expérience ? La réponse est non. Est-ce qu'il faut 10 ans ? Malheureusement, la réponse est oui. Est-ce qu'il faut avoir vu des centaines de projets ? Je pense que oui. Donc, c'est pour ça aussi que, de ce point de vue-là, les agences digitales, c'est génial, parce qu'on voit plein, plein, plein de projets. Est-ce qu'à un moment donné on est fatigué de faire ça ? Peut-être mais on voit une telle diversité de projets, de problématiques qu'on apprend beaucoup beaucoup plus vite que travailler pour une startup où on voit que très peu de choses au final, enfin en tout cas ça dépend des startups mais potentiellement on peut voir très peu de choses, donc est-ce que le LLM les LLM ou l'AI en règle générale va changer l'open source ? Je pense que oui, revue de code beaucoup plus rapide, donc on va pouvoir automatiser beaucoup plus de choses, il y a 20 ans je regardais c'était en subversion à l'époque moi j'ai connu le CVS à l'époque, mais subversion sur Symfony je revoyais toutes les contributions je mergeais toutes les contributions je lisais tous les tickets je lisais tous les forums et puis au fil des années, les forums je peux plus les issues je peux plus et puis on fait de moins en moins de choses et on partage le travail de plus en plus et je pense qu'avec l'EI on va avoir cette capacité à un moment donné de dire « Ok, moi, je suis humain, je vais pouvoir plus interagir avec les gens de façon intéressante et moins de faire du travail qui, au final. N'est pas si intéressant que ça. » D'ailleurs, je suis connu pour tout automatiser. La première fois où j'ai fait une release en live durant une conférence, les gens étaient morts de rire parce que j'automatise tout. Et donc, même quand je merge une pull request, il y a un moment donné, je remercie la personne. Je pense que c'est important de remercier. Et oups, en fait, je l'automatise. et donc je me suis fait un choix de 5-6 possibilités et donc je dis tiens là, il y a merci ou enfin voilà j'ai quelques possibilités je choisis en fonction de ce que la personne a fait si c'est un bug fixe ou si c'est une nouvelle fonctionnalité une petite une grosse etc après je choisis comment je vais appeler la personne add quelque chose ou directement le prénom et boum et ça fait le commentaire, toute cette automatisation là avec l'AI on va encore aller au-delà au-delà de ça maintenant on remplacera jamais l'humain Jamais. Parce qu'au final, le code, c'est aussi une intuition. C'est aussi une philosophie. C'est des choses que l'AI pourrait être capable de le faire, mais je pense qu'on n'a pas envie d'aller là. En tout cas, moi, je n'ai pas envie d'aller là. Peut-être parce que je suis trop vieux aussi. Je ne suis pas sûr que ça réponde à la question.

Bruno:
Alors si, d'une certaine façon, mais ça m'en donne deux autres questions. La première, c'est... Tu racontais effectivement, on a connu un truc assez similaire, c'est qu'on est arrivé dans un contexte où il y avait une complexité naissante et qu'on a pu apprendre sur cette complexité, qu'on avait des outils qui ne fonctionnaient pas toujours très bien et qu'on a pu appréhender en testant et en bricolant et qu'on a grandi avec cette complexité. Et après tu nous parles du coup des LLM qui sont et en fait c'est au final un peu la même chose que les devs d'aujourd'hui qui arrivent aujourd'hui, expérimentent, c'est qu'ils arrivent sur un secteur avec des outils qui sont pas encore hyper matures, qui font des trucs qui sont pas encore hyper carrés, mais qui vont gagner en complexité et en fait ils vont apprendre aussi avec cette complexité qui augmente et au final ils vont apprendre à faire un métier qui n'est au final pas le métier que toi et moi, on a appris à faire.

Fabien:
Ce n'est pas le même. Ceci étant, quelques recommandations, en tout cas de mon expérience de l'usage de l'AI ou des LLM en règle générale sur du code. Un, ne jamais comité du code qu'on ne comprend pas, qui a été généré automatiquement et qu'on ne comprend pas. Ça, j'ai à proscrire absolument. Deux, je pense que pour un développeur un peu plus junior, le truc qui est incroyable avec les LLM, c'est de leur poser des questions, c'est que ça remplace la documentation. Ça remplace ta cover flow, comme tu le disais, ça remplace la documentation, ça remplace tout ce qu'on peut avoir comme apprentissage, peut-être même les formations ou les choses comme ça. Moi, sur des sujets que je ne maîtrise pas bien, Le LM, je fais une recherche sur Google et j'utilise DocGo en l'occurrence, pas Google, mais j'ai du mal à trouver quelque chose qui soit vraiment pertinent. Et généralement, quand je pose la question à Claude, à ChatGPT, il y a un truc pertinent. Ou en tout cas, ça me permet de mettre le pied à l'étrier et de dire « Ah, ok, c'est plutôt bien vu ». Ça me permet d'aller à l'étape d'après. Mais je l'utilise assez peu pour générer du code que je vais garder, en tout cas, que je vais garder. C'est très, très rare. Ou des trucs vraiment à la con. Je l'utilise beaucoup pour automatiser. J'ai un gros fichier avec plein de trucs et je veux changer la même chose. Je le fais une fois et il comprend le truc et boum, il me le fait automatiquement. Mais même ça, il ne sait pas bien le faire. Je l'ai fait l'autre jour sur un projet je ne sais plus ce que c'était et je lui ai demandé vraiment de façon très très spécifique de changer que ça et il a été me changer des trucs qui n'avaient rien à voir et il a tout cassé donc il faut être vraiment critique par rapport à ça, d'ailleurs moi le LLM le prompt engineering je ne m'emmerde pas la vie, je lui dis j'ai une erreur, je lui coupe colle l'erreur je ne lui dis pas ah tiens monsieur LLM s'il te plaît il y a une erreur non non je lui colle l'erreur et il s'en fout lui l'erreur, il me dit ah bah tiens je pense que c'est ça ah ouais t'as raison, ok.

Bruno:
Alors il s'en fout mais il y a quand même des tests ou des études qui montrent que la formule de politesse te donne des réponses différentes et d'une qualité différente ouais différente.

Fabien:
Est-ce qu'elles sont meilleures ? Je ne suis pas persuadé moi mon expérience c'est que ça marche comme ça. Tu sais il y a aussi des études qui disent si tu mets des fautes d'orthographe, et bah il peut avoir une réponse qui est meilleure t'as vu ça ? Ah non ça je l'ai pas vu par exemple. Donc il y a un moment donné moi je me prends pas la tête, je me prends pas la tête aussi parce que je sais que tout ça ça va évoluer. Et les bonnes pratiques du prompt engineering d'il y a deux mois ou d'il y a six mois ne sont plus les mêmes aujourd'hui. Je ne me prends pas la tête. Je pose ma question comme je te la poserai à quelqu'un, tu vois, quand tu fais du per-programming, tu ne commences pas à dire « Bon, alors, est-ce que tu peux, s'il te plaît, commencer ? » Non, tu dis « Bon, on va faire ci. Tiens, regarde, il y a une erreur. On est direct. Le LLM, il s'en fout. Donc, autant être direct. » Par contre, ce qui est vrai, c'est que quand je lui pose une question et que je ne suis plus sur de la doc ou de l'apprentissage, j'apprends quelque chose de nouveau. Là, mes prompts sont un peu plus précis. D'abord, pas très précis. Et une fois que je commence à comprendre, je suis beaucoup plus précis dans ce que je lui demande pour qu'il soit vraiment spécifique et que j'ai des réponses qui soient pertinentes. Je donne un exemple où ça m'a super aidé. Notamment, je reviens sur Twig pour filer le truc jusqu'au bout. Un des trucs que j'ai fait, c'est que j'ai revu comment on parsait les expressions. 1 plus 2 plus 4, différent de A versus je ne sais pas quoi, pipe bidule. Sujet super intéressant. Allez, si vous avez deux minutes, allez voir ce que c'est qu'un parseur Pratt. P-R-A-2-T. De temps en temps, dans une vie de développeur, en tout cas dans ma vie, il y a 4 ou 5 fois où j'étais complètement sidéré d'un concept, d'un truc qui résout un problème hyper compliqué, de façon super élégante et hyper simple. Prat-Parsing. C'est ce qu'on a dans Twink maintenant. Bitcoin, c'en est un autre. Pas l'aspect financier, machin, etc. Mais les 3 concepts, les trois problèmes que résout Bitcoin et comment il les a résolus c'est oh ! Pareil deuxième recommandation à faire si vous n'avez pas lu le papier d'origine de Bitcoin il faut le faire c'est trois pages quatre pages je ne me rappelle plus ça fait longtemps que je ne l'ai pas lu mais c'est juste une révélation, on est très loin d'ailleurs de ce truc là aujourd'hui dans les cryptos, et ça me permet d'avoir complètement oublié la question on.

Bruno:
Parlait de comment est-ce que l'LLM impacte la manière dont on code, la génération de code. Et tu parlais de... Du coup, moi aussi, je me suis perdu dans le Twig.

Fabien:
J'avais trois recommandations, je les ai oubliées du coup. Comment j'utilise l'LLM, c'était ça, quelque chose comme ça. Plutôt pour la documentation et plutôt pour apprendre des choses. Je trouve ça génial. Donc, voilà. C'était sur Twig. Donc, les expressions. Et à un moment donné, on a des problèmes dans Twig, qui est la précédence des opérateurs. Donc, facile, multiplié versus plus. Facile. Mais après, il y a l'associativité. Il y a associativité à droite ou à gauche. Et puis après, il y a les trucs spécifiques de Twig. Appel de fonction, pipe pour les filtres. D'ailleurs, on revient à Spip. Tous ces trucs-là. Ça doit être quoi ? Et c'est quoi l'opérateur Turner, par exemple ? Très intéressant. Non associatif, par exemple. Et en fait, j'ai posé un LLM, je lui ai dit, ok, c'est quoi les bonnes pratiques ? C'est quoi ? Donc, donne-moi la présidence des opérateurs en C, en Ruby, en Python et en PHP. Il me fait un truc, je dis, non, non, fais-moi un tableau récapitulatif. Hop, il me fait le tableau récapitulatif, et boum, boum, boum, ok, bon, ben voilà, j'ai ma réponse. Et après, je lui dis, bon, ben ok, moi j'ai des filtres en Twig, voilà ce que c'est des filtres, etc. À ton avis, ça doit être où dans les hiérarchies ? Il me dit un truc, c'est bon, c'est pas bon, mais en tout cas, ça me donne un point de départ. Et super utile.

Bruno:
Ça défriche les trucs.

Fabien:
Ouais, complètement.

Bruno:
J'ai une espèce de conviction qui est en train de, grandir et c'est sur le fait que cette réflexion de l'impact du LLM sur le métier de développeur elle est biaisée parce qu'on continue à envisager le comment est-ce qu'on va créer du code, parce que je sais pas si t'as vu en décembre Satian Adela sorti un édito Sass is dead, qui était assez intéressant et moi ce que je en tirant le fil et ce que j'en ai compris aussi c'est qu'au final, on pourrait avoir demain une IA agentique qui reçoit ta requête en HTTP, qui te ressort du HTML pour un client et qu'en fait on n'ait plus besoin de générer du code mais qu'en fait le métier de créateur d'application de créateur de service ne passera même plus par la génération de code et donc le fait que nos LLM ne nous apprennent plus à coder, c'est peut-être pas un problème parce qu'en fait l'idée, c'est qu'on n'aura peut-être plus besoin de coder.

Fabien:
Ouais. Jamais voulu que mes enfants soient développeurs. Ça fait longtemps, mais ils ont 17 et 19 ans. Aussi pour cette raison. Parce que très tôt, je me suis dit, en fait, ce métier-là, c'est pas un métier d'avenir. Le métier de développeur, c'est quelque part le mec qui était à la chaîne il y a 100 ans. C'est un peu ça. Donc, c'est un métier qui va vachement se dévaloriser.

Bruno:
On parle d'ailleurs d'usine logicielle.

Fabien:
Ouais, effectivement. Qui est peut-être déjà un peu dévalorisé aujourd'hui, déjà un peu. Ceci étant, effectivement, il y aura de moins en moins de valeur, certainement, à faire du plumbing de briques logiciels, parce que ça, c'est pas très compliqué. Par contre, quand on parle de logique métier, et moi, j'ai toujours été un grand fan de dire, en fait, le métier de développeur, c'est pas tellement ce plumbing. C'est pour ça que j'ai fait Symfony, parce que c'est pas intéressant, en fait. C'est pas intéressant de créer un contrôleur ou quoi que ce soit. Ce qui est intéressant, c'est de comprendre le besoin du client et de comment on va implémenter cette logique métier. Et ça... Pas dans tous les cas, mais dans un certain nombre de cas, il y aura besoin de jus de cervelle, encore. Et je pense que c'est... C'est pour ça aussi que je crois que le métier de développeur, ce n'est pas un métier de gens qui sont dans une cave, en fait. C'est des gens qui doivent être en contact avec les clients, qui doivent avoir... Et encore un bon point pour les agences digitales, je ne sais pas si c'est le cas encore aujourd'hui, mais en tout cas, à mon époque, les développeurs très régulièrement étaient en contact avec les clients pour comprendre la problématique et pour trouver des solutions à des problèmes. Et je vois plus un développeur comme étant quelqu'un qui trouve des solutions à des problèmes plutôt que quelqu'un qui est là pour pardonne-moi l'expression, pisser de la ligne de code mais ça je pense que c'est déjà le cas il y a 10 ans 15 ans.

Bruno:
20 ans honnêtement je suis extrêmement aligné avec tout ça, écoute c'était passionnant merci beaucoup Fabien pour cette conversation, merci à toi j'aurais deux dernières questions pour toi qui sont les questions rituelles du podcast la première c'est est-ce qu'il y a un contenu que tu saurais partager avec l'ensemble des auditeuristes ?

Fabien:
Alors, oui. Et heureusement que tu peux poser la question avant, parce que ça m'a permis de réfléchir. Il y a un bouquin écrit par Paul Graham qui s'appelle Hackers and Painters. Alors, je l'ai lu il y a très, très, très, très longtemps. Mais ça m'avait plu, en fait. Donc, l'idée, c'est de dire, tiens... Le métier de développeur, hacker, il se rapproche aussi d'un métier painter, painter au sens peintre du bâtiment, painter au sens artiste. Ça, ça peut être un débat de savoir est-ce qu'on est des artistes ou pas ?

Bruno:
On y a répondu sur ce podcast.

Fabien:
Ouais, je pense. Est-ce qu'on est des artisans ? Et en tout cas, le bouquin est super intéressant. Paul Graham, si vous... Tout le monde connaît Paul Graham dans sa vie actuelle, mais je vous invite à voir comment il en est arrivé là et c'était quoi sa première société qu'il a créé et comment il a eu du succès super intéressant aussi donc ça serait ce bouquin là je.

Bruno:
Pense très bien et dernière question la plus importante de ce podcast est-ce que tu es plutôt espace ou tabulation.

Fabien:
? elle est super simple elle est super piégeuse évidemment, espace évidemment puisque Symfony on fait des espaces et que PHP à un moment donné a décidé d'utiliser des espaces il se trouve que je fais énormément de go aussi et qu'en go c'est des tabulations, donc j'ai envie de dire je vais me fâcher avec personne ce soir les deux mon.

Bruno:
Capitaine les deux mon capitaine très bien merci beaucoup Fabien merci à toi et merci à tous d'avoir écouté cet épisode, conversation très riche bien évidemment sur beaucoup de sujets en tout cas je pense qu'un des messages clés c'est contribuer à de l'open source tant que ça existe en tout cas, faites-vous plaisir ça peut commencer par des petites des petites issues des petites requests et puis petit à petit vous montez en gamme on avait déjà eu pas mal de gens qui nous ont expliqué aussi vous pouvez commencer par faire de la doc c'est aussi quelque chose qui est très nécessaire, donc n'hésitez pas, lancez-vous et effectivement aussi publiez des choses, dans un esprit de communauté et pas uniquement de show-off de marketing, c'est aussi ça la base de l'open source de gauche comme nous l'a expliqué Fabien. Moi je vous remercie comme toujours de partager aussi ce podcast autour de vous c'est aussi une forme de partage je vous souhaite une très bonne fin de semaine je vous dis à la semaine prochaine et d'ici là codez bien.