Code-less to dev-more

Bruno:
Dans notre métier, il y a toujours deux façons d'aborder les choses. Soit on écrit du code, soit on développe des solutions. Mais si ces deux activités étaient finalement bien différentes ? Le no-code en entreprise vient bousculer cette frontière. Il ne s'agit plus de coder pour coder, mais de construire rapidement, efficacement, parfois même sans taper la moindre ligne de code. Et quand l'IA s'emmêle et commence à générer du code à la volée, difficile de ne pas voir un futur où codé devient un accessoire. Le développement, lui, reste essentiel. De Python à Xano, des scripts maison à briques visuelles, le glissement est déjà en cours. Le code n'est plus la seule porte d'entrée vers la création d'outils. Et surtout, il n'est plus réservé au seul développeur. Mais alors, comment intégrer le no-code dans un SI existant ? Que faire de tout ce legacy qui refuse de mourir ? Et surtout, si on ne code plus, que devient le métier de dev ? Pour répondre à ces questions sans parenthèse, je ne reçois pas Alan Turing, mais il s'y connaît en logique. Frédéric, bonjour.

Frederic:
Bonjour.

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

Frederic:
Avec plaisir. Donc Frédéric Najman. Alors moi, j'ai un profil tech, clairement. Je suis ingénieur en informatique, mais aussi en électronique d'ailleurs. J'ai fait une thèse d'entreprise spécialisée en intelligence artificielle sur les réseaux neuronaux, la computer vision, mais bien avant que ça devienne le buzzword. C'était passionnant. Donc, pourquoi je dis ça ? C'est parce que souvent, il y a nos codes, ce n'est pas pour les techs, etc. Moi, c'est vraiment mon parcours. J'ai écrit des livres d'ailleurs sur Java, aux éditions AeroHall, sur les architectures client-server, sur le développement Windows CE, pour ceux qui connaissent encore sur les premiers mobiles. J'ai été aussi mentor chez Google, Google Campus, j'enseigne de temps en temps aussi à la fac, donc vraiment un profil tech, clairement développeur et aussi aujourd'hui je suis CTO as a service, donc j'interviens sur des vrais gros sujets d'architecture notamment chez les corporates, autour des architectures informatiques et plus spécialement autour du sujet du no-code et je suis aussi et surtout évangéliste chez Xano évangéliste tech qui est une plateforme de back-end aujourd'hui, leader, que j'adore. Ce n'est pas par hasard que je suis chez Xano. Peut-être qu'on en reparlera à titre d'exemple.

Bruno:
Carrément, alors moi j'ai déjà raconté plusieurs fois à ce micro effectivement mon passé de dev et comment est-ce que j'ai découvert le no-code et comment est-ce que je suis tombé dedans, je serais curieux de savoir comment est-ce que toi avec ton passé de développeur t'as découvert le no-code et qu'est-ce qui t'a fait basculer sur, il y a un vrai avenir là-dedans.

Frederic:
Alors c'est une bonne question, d'abord moi je vais mettre un peu les pieds dans le plat peut-être je vais mettre un peu les pieds dans le plat parce que j'aime pas les gros mots c'est une révolution industrielle etc etc il y a beaucoup de buzz marketing. Moi je trouve qu'on y est arrivé au no code naturellement, ce que je veux dire c'est que dans les années 70 on développait en C et puis, ensuite dans les années 80-2000 on a commencé à avoir des langages plus haut niveau, le Java le Python, le C++ on a commencé à créer finalement des, objets, métiers aussi, des librairies donc finalement on était dans le less code je ne sais pas s'il faudrait inventer un terme mais on est passé du code au less code, pourquoi ? Parce qu'on voulait réutiliser. Et Aya, pour moi, on était déjà dans une démarche qui était de dire, moi, pour moi, un bon développeur, c'est un développeur un peu fainéant quand même. Enfin, on est tous d'accord. On est d'accord. Enfin, nous, premier réflexe, et ça a toujours été, en tous les cas, depuis les années 80, c'est de se dire, tiens, il n'y a pas une librairie qui fait ça, il n'y a pas un code qui fait ça. Évidemment, on ne cherchait pas sur Internet parce qu'il n'y avait pas forcément tout ça. Mais donc, 82 000, les langages évoluaient. À partir de 2000-2010, on arrive sur des frameworks. React, Django, Laravel, c'est pareil, on arrive sur des stacks avec des outils qui nous permettent d'aller plus vite et de moins coder donc je pense qu'il ne faut pas tirer sur l'ambulance en tant que développeur parce qu'en fait du no-code on en fait depuis toujours. Et là on voit bien que depuis 2010, moi je date à peu près l'arrivée du no-code, je dirais pour moi en tous les cas pour répondre à la question à peu près autour de 2010 on a vu arriver un bubble qui est intéressant parce que bubble c'est quand même créé par un mec qui a fait Harvard etc, polytechniciens qui sont des développeurs aussi. On reste un peu dans notre famille des développeurs. Ils ont commencé à créer ça en 2010 et je crois qu'en 2013, si je ne dis pas de bêtises, c'était déjà 100 000 utilisateurs. Aujourd'hui, on est à plus de 2 millions, je crois.

Bruno:
J'ai reçu Emmanuel, créateur de Bubble, il y a quelques semaines ou quelques mois à ce micro. Dans la quantité de ce que tu dis, il a eu une phrase que j'ai trouvée top. Il disait que Bubble est plus proche de Javascript que Javascript n'est proche, du CPU ou de l'assembleur en fait, parce qu'effectivement JavaScript c'est déjà une telle abstraction, c'est un tel niveau d'abstraction par rapport à l'assembleur qu'en fait Bubble c'est la couche juste.

Frederic:
C'est vachement bien je suis 100% d'accord avec ce que tu dis et ce qu'il dit. En 2023 Bubble c'était 2 millions d'utilisateurs donc on voit bien que c'est un produit market fit en fait qui répond à un besoin, moi à titre personnel j'ai commencé, bien loin comme je pouvais dire mais vraiment avec Bubble on va dire où j'ai commencé à me dire tiens c'est marrant moi-même je m'étais développé des outils no code pour aller plus vite, pour commencer à créer on l'a tous fait en fait d'hypocrite, on l'a tous fait, et là où j'ai vu et ce qui m'a fait vraiment changer c'est l'impact en entreprise en fait c'est l'impact ce que je regrettais un peu d'ailleurs à l'époque j'avais créé une boîte qui s'appelait Technical Input où j'essayais de rapprocher les équipes techniques des équipes métiers il y avait souvent dans les entreprises l'ADSI d'un côté, le produit market de l'autre côté, et en fait, ils n'arrivaient pas à s'entendre. Parce que dès qu'il y en a un qui voulait, l'autre disait, oh non, c'est pas possible. Et l'autre, il disait, mais attends, il vient nous demander des choses impossibles. Donc, on voit que pendant très longtemps, ça a perduré cette un peu dichotomie comme ça dans l'organisation des projets. Et là, j'ai vu arriver des produits no-code qui permettaient aux développeurs, finalement, de continuer à travailler plus vite, mais en même temps, d'arriver à impliquer à certaines parts du développement les équipes métiers. Et là, je me suis dit voilà, on y est en fait. On a toujours travaillé pour ça. C'est-à-dire que... Et c'est là où j'ai commencé à m'y mettre. J'ai testé pas mal de solutions. J'en ai benchmarké. J'en benchmark aussi toujours beaucoup. On pourra en parler plus tard, mais j'en ai rencontré d'autres qui me plaisent et d'autres moins.

Bruno:
J'ai une question qui m'a échappé. ... Ah zut, c'était sur... Ah oui, parce que je voulais dire qu'il y a une évolution intéressante dans le no-code, c'est qu'on a connu, il y a longtemps, des outils comme FrontPage, l'outil de Microsoft qui permettait de générer des sites web et autres. Je trouve qu'il y a quand même un changement de paradigme avec des Xano, des Mec, des Zepir et autres, c'est qu'aujourd'hui on est sur des outils qui ne génèrent pas de code, là où un FrontPage générait du code HTML. ML. Donc, on a eu une période, en fait, où tu pouvais générer du code tel qu'on le fait encore aujourd'hui avec des IA génératives. Mais aujourd'hui, il y a quand même une mouvance dans nos codes d'outils qui te permettent de créer des applications, de créer toute une logique sans avoir aucun moment de génération de code en avoir à proprement parler.

Frederic:
Alors, je suis d'accord avec toi dans le fait qu'on ne voit plus le code généré par rapport à avant où on se retrouvait avec du code. C'est un peu ce qui se passe encore aujourd'hui avec l'IA qui génère du code. C'est-à-dire que ça te génère du code, maintenant qu'est-ce que t'en fais ? Après, t'as des outils comme Lovable, etc., qui vont te permettre de pas trop y toucher, mais quand même effectivement, on voit... Mais derrière, ça génère quand même du code. Enfin, je veux dire, in fine, par exemple, tu vas prendre un WeWeb, il va te générer un stack en Vue.js que tu peux hoster sur ta machine, ou que tu peux hoster on-premise, ou que tu peux le laisser dans un SaaS, ou quoi que ce soit. Et d'ailleurs, ce qui est hyper intéressant, justement, pour les développeurs, c'est que ce code généré, tu peux le retoucher, si tu veux. Alors bon, après, tu peux plus faire de reverse, mais Mais c'est quand même super intéressant. D'ailleurs, j'ai souvent des questions chez des corporate comme ça, qui me disent, ok, mais si demain, par exemple, Xano disparaissait ? En fait, Xano, c'est basé sur des stacks open source. C'est du PHP et ça te génère tout ça, en fait, derrière. C'est des bases de dépose grée. Enfin, on est dans notre zone de confort, donc il n'y a pas de raison d'en avoir trop peur. On reste dans les zones de confort. Si tu prends un Flutter Flow, ça te génère, par exemple, du code Flutter, que tu peux très bien récupérer et éditer à la main. Mais par contre, là où je suis d'accord, c'est que c'est moins visible, c'est-à-dire tu peux t'en passer complètement. Si t'es pas un codeur ou t'as pas envie de rentrer dans des logiques de code tu peux complètement t'en passer. Mais si par contre t'es codeur et t'as quand même envie de, tu peux le faire. Et c'est ça que je trouve très intéressant entre le less code, low code, no code, enfin après on peut redéfinir peut-être en tout cas ma vision de ces termes-là mais chacun peut être servi en fonction de son profil. Le métier il va pas vouloir du tout avoir accès au code surtout pas quoi. Alors que le codeur un peu de base, lui, il est rassuré de savoir qu'à n'importe quel moment, il peut ouvrir le source et le lire.

Bruno:
Mais est-ce que justement le codeur, il n'est pas inquiété ou... Enfin, pas inquiété, peut-être pas le bon mot.

Frederic:
Mais... Menacé !

Bruno:
Ou en tout cas, il n'apprécie pas le code généré par l'outil parce qu'il n'en est pas l'auteur.

Frederic:
C'est clair. Là, il y a un gros sujet. Le développeur, aujourd'hui, dans l'adoption du no code, j'ai envie de dire que ce n'est peut-être pas celui qui va y aller plus naturellement par rapport au métier, par rapport à d'autres. C'est vrai que pour moi, le métier de développeur, c'est pas que codeur. Dans le métier de développeur, tu as l'architecte, tu as choisir les solutions, les algorithmes, etc. On voit bien que le métier aujourd'hui d'un développeur et notamment de la partie codeur du métier de développeur, c'est aussi beaucoup d'assemblage. Et moi pour moi alors déjà j'aime pas le terme no code, je trouve que c'est très mal parti parce que no code ça commence avec no et c'est une négation et je trouve que d'un point de vue marketing même, proposer un outil qui commence par une négation c'est pas génial, c'est pour ça qu'aujourd'hui il y a un espèce de mouvement de dire on va plutôt appeler ça du modern programming ou du visual development il y a une approche quand même moins no, et beaucoup de gens qui entendent no code, ils entendent no codeurs et no codeurs pour eux ça veut dire no developers, donc ça veut dire que ces milliers de gens qui sont formés au développement vont disparaître. Moi, je ne le vois pas du tout comme ça, bien au contraire. Moi, ce que je vois à travers les outils low-code, no-code, c'est juste un outil de plus dans la panoplie du développeur. Donc, le développeur, on a dit, il a des librairies, il a ses frameworks. Il a l'IA, on peut en parler, mais l'IA, c'est un vrai sujet aujourd'hui pour le métier du développeur. Et puis, il a aussi des stacks no-code. Il a du Xano, du Rtable, d'autres comme ça. Et en front, il peut avoir du Bubble, il peut avoir du WeWeb ou du Flutter Flow, il y a plein d'outils. Et à lui de se dire, en fonction du besoin, de la question qu'il doit régler. Choisir dans sa besace les bons outils. Et moi, ce que je trouve hyper intéressant, c'est de te dire, là-dessus, il n'y a pas un gros challenge, je n'ai pas besoin d'aller, moi, réécrire du code que j'ai écrit mille fois, je vais prendre, par exemple, un Xano pour créer mon backend qui va me générer effectivement mon code et toutes les APIs. Et là, pour répondre à ta question, je pense qu'il y a deux manières de voir. Soit je suis super inquiet parce que ce n'est pas moi qui ai écrit le code. Donc là, je me dis qu'est-ce qu'il m'a fait comme code et tout. Je peux toujours aller voir. Mais soit au contraire, je me dis ça, par exemple, Xano, c'est des anciens de chez Google qu'ont créé ça. Sean et Prakash, ils ont travaillé sur Google Photo, plus grosse plateforme de photos au monde. On pourrait se dire avec les 50 développeurs qu'il y a derrière qui sont tous des tronches, que le code qui est là, il est hyper optimisé. Peut-être même mieux que ce que moi, codeur, je pourrais faire dans le temps que j'ai pour le faire, donc finalement pourquoi aller moi réécrire et finalement on le faisait déjà avec des DLL par exemple ou de toutes ces choses là donc pourquoi aujourd'hui ça nous pose un problème ça posait pas un problème d'utiliser une DLL mais ça pose un problème d'utiliser un outil no code alors finalement pour moi c'est la même philosophie tu vois et si je suis un CTO et là je me positionne je me dis c'est génial parce que j'ai une sorte de couche qui va uniformiser la qualité des développements parce que le problème souvent dans les équipes de développeurs c'est qu'on a différentes séniorités, différentes approches, parfois même des stagiaires qui n'ont pas forcément... Je n'ai rien compris des stagiaires, mais c'est pour dire qu'ils n'ont pas forcément la culture du code de l'entreprise. Donc, on va se retrouver des fois avec des morceaux de code très hétérogènes. Alors qu'en se disant, tiens, on va partir sur un outil qui va générer le code, on reste sur un certain standard aussi. Du coup, donc...

Bruno:
Oui, mais tu peux... Tu n'es quand même pas à l'abri aussi que la manière dont tu vas utiliser Xano, va générer du code plus ou moins différent et va faire que tu as quand même une hétérogénéité entre le stagiaire qui découvre la plateforme et un expérimenté ou un senior qui la pratique depuis un plus long moment.

Frederic:
Oui, alors tu as 100% raison. On va dire que la logique, parce que finalement, ce que tu fais après, c'est surtout de la logique presque plus que du code en tant que tel, mais c'est sûr que ça peut générer des choses différentes. Mais prenons un exemple, je ne sais pas, la sécurité. Tu vois, tu te dis, moi, je veux être sûr que toutes mes APIs sont sécurisées. Tu vas dans Xano et tu dis, voilà, ce endpoint, cette API, elle est private. Automatiquement, tout le système de sécurité, il est mis en middleware, sur tout ton stack de endpoints. Tu n'as pas à t'assurer que ton stagiaire ou ton codeur ait bien suivi les guidelines et de sécurité pour chacune des API. Ça, c'est quand même une certaine confort. Après, ce que je veux dire par là, c'est que une plateforme comme Xano, c'est no code, mais c'est aussi low code. En Xano, tu peux faire du JavaScript, tu peux faire du TypeScript, tu peux même apporter tes packages sous Dino, tu vois, NPM. Donc, tu peux vraiment, si tu as envie, rentrer dans code. tu peux créer alors tu n'as pas besoin de faire ton SQL si tu n'as pas envie visuellement tu accèdes à tes données dans la base de données embarquée Postgre ou ta base connectée mais tu peux aussi faire du SQL donc c'est pas parce que tu fais du no code low code que tu ne peux pas aussi aller faire plus du spécifique et là pour le coup tu retombes on va dire par rapport à ta question, dans effectivement les problèmes de qualité contrôle du code etc.

Bruno:
Pour citer à nouveau Emmanuel sur son épisode avec Bubble où on avait cette discussion ce qui était intéressant avec Emmanuel c'est qu'il nous expliquait que Bubble ne s'adresse pas aux développeurs, la population cible c'est quand même des gens dont ce n'est pas le métier mais quand on avait ces sujets effectivement de l'avenir du dev et autres il m'a fait une phrase qui est tergote il dit avec Bubble on peut faire des bugs, Donc, tu peux générer un bug, en fait. Donc, ça en devient un vrai outil technique, parce qu'en fait, si tu ne le maîtrises pas bien, tu génères des erreurs. Est-ce qu'avec Xano, de la même façon, tu peux générer des bugs ?

Frederic:
Tu peux générer des bugs. Et aussi, le métier de développeur, c'est de faire des algos. Tu continues à faire des algos et tu peux voir qu'entre deux no-codeurs développeurs, tu vas en avoir un qui va faire un outil hyper performant et il a mis les... Tu vois, parce que tu as quand même différentes façons de faire. Et c'est là que je trouve que c'est une vraie opportunité pour les développeurs d'aujourd'hui. C'est-à-dire que, après, je ne peux pas parler pour tous les développeurs. Moi, personnellement, j'adore coder, mais j'en peux plus de coder toujours la même chose. Tu vois, quand tu développes des CRUD, des trucs comme ça, tu as l'impression que tu ne sors plus à rien. En fait, tu n'as aucune plus-value là-dessus. Je ne dis pas, tu sors d'école d'ingé, tu vois tes codes ou d'école de dev, c'est rigolo, tu sais bien faire, tu maîtrises. T'as l'impression que j'ai du piano, tu vois les yeux fermés. Mais très vite, tu te dis, attends, j'en peux plus de faire tout ça. Moi je trouve ce qui est le plus sympa dans le métier de développeur c'est vraiment de réfléchir à l'algorithmie comment tu vas architecturer tes outils, quel type aujourd'hui tu vas assembler, c'est un blend un peu le code, c'est comme un bon whisky, tu t'assembles plein d'ingrédients donc comment tu vas réfléchir à tout ça et pas forcément d'aller coder ton accès à la base de données et tout ça, Bubble c'est un peu un outil quand même un peu à part, enfin comment on va dire c'est à dire qu'il y a plein de familles d'outils Xano et Bubble ne sont pas dans la même catégorie on va dire un bubble et c'est un outil tout intégré qui est vraiment dédié. À la création de sites web à la création de sites web tu peux faire des back-end et tout ça mais c'est vrai qu'ils essayent d'aller sur le créneau de ceux qui ne sont pas des développeurs, Xano pour répondre à ta question c'est plus un outil qui va quand même s'adresser à des développeurs ou en tous les cas à des gens du métier ce qu'on appelle les citizen developers des gens du métier qui ont une appétence quand même à la technique. Oui tu peux générer des bugs en Xano heureusement d'ailleurs parce que ça veut dire que ça reste un outil quand même qui reste technique, mais t'as beaucoup plus de garde-fous, tu vas beaucoup plus rapidement et surtout, tu recodes pas constamment les mêmes choses, donc le fait de pas recoder, tu minimises aussi le risque de nombre de bugs. Ce qui est hyper intéressant sur des plateformes comme ça, il n'y a pas que Xano qui font ça, mais t'as des outils de tests aussi intégrés, tu vois, de non-régression, etc. Donc tout est là pour que tu puisses rapidement assembler ta logique et suivre, mais t'as les sujets de performance, t'as des débuggeurs, d'ailleurs. Il y a un débuggeur incroyable dans Xano, ce qui prouve bien que potentiellement, il y a des bugs. il peut avoir des bugs mais quand on a connu le monde du dev où il suffisait qu'il y ait un point virgule qui manque ou un truc comme ça et qu'on pouvait passer des heures à retrouver le petit problème ils vont dire mais attends je vais passer à nuer là-dessus, quelque part ça n'existe plus trop sur Exano donc on peut se concentrer en tant que développeur sur ce qu'on aime le plus en tous les cas je pense la majorité des développeurs.

Bruno:
Et sur le fait de produire de la valeur ce qui est quand même aussi.

Frederic:
La... Et ce que je trouve intéressant je trouve que le développeur d'aujourd'hui malgré tout il se rapproche quand même du métier alors peut-être pas dans tous les sujets mais souvent les développeurs en entreprise parce que là on parle beaucoup de stack quand même en entreprise, il se rapproche du métier et souvent il aime bien ça ça le sort un peu de son, ordi quoi j'ai envie de dire et il comprend mieux et tous ces outils-là ça permet aussi de se concentrer sur la brique métier et même j'irais même encore plus loin de donner la main à des gens du métier de venir influer sur le produit c'est-à-dire de presque, customiser et le développeur au final il est content parce que mettre un petit logo à droite plutôt qu'à gauche et s'il doit tout refaire sa page et tout en fait ça n'intéresse pas à priori.

Bruno:
Je pense effectivement moi que tous les développeurs et toutes les développeuses devraient effectivement se rapprocher du produit je pense que c'est important de savoir à qui, on apporte de la valeur à quel problème on va répondre et de pas être juste dans une, dans une recherche d'une beauté algorithmique ou de la ligne de code parfaite.

Frederic:
C'est tout à fait il faut.

Bruno:
Apporter de la valeur.

Frederic:
C'est Eric Evans qui avait fait la méthode DDD, qui était qui est super intéressant parce que c'est ce qu'il dit en fait dans son bouquin et ce que je trouve hyper intéressant c'est que c'est un bouquin qui a été créé je sais pas quand il a lu moi j'ai dû le lire en 2014 peut-être un truc comme ça Donc il y a bien 10 ans. Mais tu vois que déjà, lui, ce qu'il dit, c'est que le code doit finalement s'approcher de la logique métier. Peut-être qu'il y a 10 ans, c'était quoi ? Mais non, nous, on fait des briques et tout ça. Mais en fait, ça pourrait complètement s'extrapoler dans le milieu du no-code aujourd'hui. Son bouquin, il faudrait presque qu'il réécrise aujourd'hui dans la logique no-code.

Bruno:
Je suis complètement aligné. Le DDD, j'en parle à multiples reprises sur ce podcast que je suis effectivement un grand fan du concept. Quand on parle effectivement de Citizen Developer, qui est effectivement une approche qui est intéressante, j'ai envie de le mettre en parallèle avec le Vibe Coding, qui est une mouvance qui commence à prendre de plus en plus d'ampleur. Je ne sais pas si tu as vu, ça a buzzé il y a quelques semaines sur LinkedIn. Il y a quelqu'un qui a mis en... Qui a créé un service avec du code qu'il a généré, intégralement par ChatGPT en faisant tout un effet d'annonce, en disant regardez, j'ai fait en place tout un outil SaaS, toute une API, je ne sais plus ce que c'était exactement, en disant je ne suis pas développeur et puis j'ai utilisé ChatGPT pour générer un truc, et je crois que quelques heures après, il a dû décommissionner l'ensemble parce qu'en fait, comme c'était codé par quelqu'un qui n'était pas développeur et fait uniquement avec ChatGPT, il y avait effectivement plein de zones, problématique et donc qui s'est fait surcharger enfin il.

Frederic:
Y a eu le good buzz et le bad buzz.

Bruno:
Exactement complètement derrière et je pense que tu vois effectivement des outils comme Xano mais aussi comme d'autres moi j'utilise beaucoup Make, Rtable et autres en fait sont des moyens pour des citizen developers de créer des de créer des applications de créer des services dans des écosystèmes qui sont, entre guillemets beaucoup plus maîtrisés et qui leur permettent de faire des choses plus propres que ChatGPT écrivez-moi une application en réel.

Frederic:
Moi, ce que je trouve intéressant avec l'arrivée de l'IA, tu vois, les cursors, Lovable, des outils comme ça, c'est que tu vois, que ce soit Mech, tu parlais de Airtable ou de Xano, c'est qu'en fait, l'IA est maintenant embarquée dans le produit. C'est-à-dire que tu vois, je trouve que c'est vraiment le mariage parfait. Parce que avant, tu développais avec des plateformes no-code, donc tu étais un peu dans du visuel. Mais il y a un moment, tu te dis, tu vois là j'ai pas longtemps j'étais sur un sujet ah j'ai un fichier Excel que je veux importer mais c'est pas dans un encodage tu vois typique mais ça marche pas etc donc là typiquement t'es un peu dans l'angle mort du rétroviseur où l'outil no code ben il est fait pour tout le monde mais il est pas fait pour du spécifique donc là t'as besoin un moment de faire du low code du code voir tu vois, et là il y a deux solutions donc soit t'es codeur soit t'as des codeurs dans ton équipe soit tu veux prendre des codeurs et tu lui dis voilà j'ai besoin que tu me développes une routine en javascript typiquement que je vais intégrer dans ma brique, nous chez Xano on appelle ça des lambda donc on va mettre ça dans une lambda qui va être intégrée à la fonction stack tu vois à toutes les fonctions donc je vais créer ma fonction dehors un peu du visuel qui est spécifiquement un code javascript par exemple euh, Donc là, tu es dans le low-code, ce qu'on appelle un peu le low-code. Mais tout le monde n'a pas des coders. Donc là, le premier réflexe, c'est de te dire, tiens, je vais utiliser l'IA. Je vais me mettre sur un chat GPT like, ou copilot, ou un truc comme ça, GitHub copilot, et je vais lui demander de me créer. Donc tu lui dis, je vais créer. Le problème, c'est que lui, il n'est pas dans l'écosystème Xano, quand même. Donc tu vas le faire à l'extérieur. Ensuite, tu vas le ré-importer dans ta lambda sur Xano. Mais il y a quand même des spécificités pour faire parler Xano low-code. Et là, si t'es pas codeur, alors soit t'es codeur, un peu feignant, tu l'as fait sur ChatGPT, positivement feignant, tu l'as fait sur ChatGPT, tu l'importes, et là tu te dis, comment je mets mes variables pour faire parler les deux ? Soit t'es pas codeur et t'es un peu... ça marche pas quoi. T'as un super code d'un côté, t'as un super stack de l'autre, mais il y a juste un moment, le dernier kilomètre, tu sais pas le connecter quoi, c'est tout. Et ça te prend plus de temps que peut-être même si t'avais fait ton propre code. Et là arrive l'intégration de l'IA dans les produits no code. Et c'est ça qui est génial, c'est que l'IA dans les produits de no code, elle a été spécifiquement entraînée d'un côté pour avoir ingurgité des milliards de lignes de code pour savoir coder un script en javascript, mais aussi il a été entraîné sur. L'outil lui-même Oxano en l'occurrence, mais ça peut être pareil chez les autres pour pouvoir faire la translation, et ça c'est génial parce que t'es dans ton même écosystème tu développes, tu dis là j'ai besoin d'un spécifique j'ouvre mon low code, ma partie low code mon lambda, et bam, tu te retrouves avec ta fonction qui fonctionne, et la quintessence là par exemple typiquement sur Xano c'est qu'ils ont créé le Xano script qui est une sorte de langage proche de Java on va dire mais metascript mais spécifiquement fait pour, l'IA et même récupéré du legacy c'est à dire que demain typiquement tu pourras avoir un j'exagère en disant un cobol to Xano mais tu pourrais au moins avoir un Python to Xano, parce que justement ça va te permettre de faire donc pour moi il y a une convergence mais évidente aujourd'hui et pour finir, ce qui est génial pour ceux qui l'utilisent l'IA pour créer du code c'est, après comme tu dis tu dis mais je fais quoi moi avec tous ces morceaux de code en plus tu sais même pas si t'as tout à fait les droits là dessus parce que c'est pas sur quoi il a été entraîné que le code ça peut être aussi protégeable, donc je me demande demain enfin je sais pas c'est pas un sujet que j'entends beaucoup parler mais je me dis à un moment imagine tu retrouves un bout de code d'une boîte qui avait protégé tu vois il y a de l'IP dessus et qu'il arrive à prouver qu'en fait c'était ton code que t'avais déposé alors qu'en fait c'est ChatGPT qui s'est inspiré il y a une espèce de flou là-dessus, aujourd'hui avec les outils visuels tu peux assembler les bouts de code générés avec l'IA, donc en fait tu pourrais presque utiliser ces outils no code pour faire de l'assemblage de composants existants mais aussi de l'assemblage de bouts de code créés par l'IA, je ne sais pas si je me fais.

Bruno:
Bien comprendre.

Frederic:
Et on voit bien là que c'est un boulevard qui s'ouvre.

Bruno:
Le point aussi sur lequel moi je souhaitais te recevoir c'est que dans ton expérience tu as eu l'occasion soit de mettre en place, soit de voir, des outils faits en no-code ou des services faits en no-code dans des environnements, corporés, dans des grands groupes et donc à grande échelle. Et ce que je trouve intéressant, c'est que au travers de ça, on démontre qu'on sort du concept, du POC, de la démo, du test, du use case, et qu'à un moment, pour faire sérieux, il faut passer sur du code à l'ancienne. Est-ce que tu pourrais nous raconter peut-être un, deux, ou j'espère combien de projets tu aurais en tête ? Tu nous as mené dans ta besace d'usage du no-code ou low-code dans des environnements d'entreprise à grande échelle.

Frederic:
Ok, alors c'est effectivement une super question parce qu'on a un peu cette image qui peut-être qu'on arrange certains aussi d'ailleurs de le no-code s'est fait pour faire des petits POC ou à la limite des MVP. Mais après, tu passes sur un truc plus sérieux. J'en prends tes mots, mais c'est exactement ça pour le coup. Moi, c'est un peu ma bataille et d'autant plus que je viens de la tech. Donc je pense que je suis encore plus légitime on va dire pour porter ça auprès des développeurs, il y a eu le No Code Summit je sais pas si t'as vu je sais pas si t'as vu mais j'avais invité quelques-uns de mes clients sur la scène pour venir relater exactement leur expérience donc parmi eux par exemple t'avais Bivouac Bivouac c'est une des filiales de la BNP c'est le studio d'open innovation. De la BNP personne va remettre en question le sérieux de la BNP d'ailleurs il y a d'autres clients qui vont dire mais attendez si vous êtes rentré à la BNP c'est que vous avez dû passer tous les standards et c'est vrai de sécurité etc etc eux ils voient bien qu'ils ont des gros besoins métiers en interne, ils ont énormément de filiales, ils ont ils travaillent aussi en mode start-up en interne, c'est une équipe incroyable qui cherche à booster l'engagement des métiers et aussi accélérer et ça c'est un peu une redondance dans toutes les entreprises aujourd'hui c'est qu'il y a une espèce de déception aujourd'hui. De la lenteur de mettre en place des solutions en intra-entreprise donc on va dire que dans les points communs de tous ces projets il y a un bivouac par exemple qui est le studio d'Open Innovation qui met en place un stack no-code en interne pour servir, les différentes business units pour pouvoir accélérer la transformation, on avait fait monter sur scène aussi une personne tech d'Europe Assistance on est dans le monde de la science c'est comme BNP dans la finance c'est des boîtes vraiment sérieuses qui qui, pareil, font aujourd'hui des premières grosses expérimentations sur site avec des solutions on-premise complètement basées sur du no-code. Ils sont sur différents stacks, donc Zano. Et pareil, l'objectif maintenant qu'ils commencent à être convaincus c'est de prêcher la bonne parole en interne c'est pour dire voilà comment on fait maintenant pour développer plus vite donc moins cher d'être plus agile ils sont tous formés beaucoup à l'agilité, toutes ces entreprises ça fait quelques années qu'elles ont investi énormément dans l'agilité, on a un outil, on est dans la quintessence de l'agilité pour moi donc je veux dire, savoir bien l'utiliser c'est presque le point final à une démarche de transformation numérique et d'agilité, il y a des entreprises comme Decathlon, System U c'est le plus gros réseau de retail. En France ou peut-être même en Europe si je dis pas de bêtises et là vous avez à chaque fois des gens quand même assez visionnaires, je trouve qu'en France quand on est CTO et qu'on dit tiens moi je vais aller sur des solutions comme ça, nos codes on se met aussi un peu à risque c'est à dire qu'on, essaie de pousser l'innovation donc chapeau à toutes ces entreprises qui font le pas alors ils y vont à pas douce feutré et ils voient que ça marche maintenant il y en a ça fait déjà plus d'un an ou deux qu'ils sont dessus donc ils voient bien que ça marche donc maintenant ils s'accélèrent et moi toutes les entreprises que j'accompagne là par exemple ont des filiales de La Poste. Qui enfin là si vous connaissez Nicolas Fable par exemple qu'on voit souvent sur les réseaux que je connais très très bien qui travaille chez Doca Poste qui a toute une équipe de développeurs qui a développé depuis dix ans leur propre solution interne, bravo La Poste ils ont développé leur propre solution interne de no code basé sur du codely de Google, mais ils ont quand même une démarche no code lui il disait il dit clairement moi avant quand j'avais un outil métier à développer en interne j'avais une demande des métiers ça me prenait 3 ans pas 3 ans à développer mais 3 ans à faire le cahier des charges envoyer ça à l'IT à faire un devis interne que l'IT le renvoie à chaque fois il y a 6 mois d'attente parce qu'il y a des priorités et à la fin ça prend 3 ans moi aujourd'hui je le fais en 3 mois c'est pas mes mots c'est les siens et lui il travaille à la poste donc c'est ça que je trouve très intéressant donc là on voit PNP, Europe Assistance, Système U on a Belfort qui est un leader dans le domaine de l'assurance qui a fait de l'interconnexion avec des gros frameworks type Salesforce etc et qui est convaincu de basculer sur le no code donc ça sont toutes les entreprises aujourd'hui que je croise au quotidien.

Bruno:
Alors, on parlait du coup tout à l'heure des citizen developers. Dans ces grands groupes, qui est-ce qui est en charge de créer ces applications dans un environnement de no-code ? Est-ce que du coup, c'est les départements marketing, business ou je ne sais quoi qui vont créer eux-mêmes leur logique ou ça incombe encore une fois à l'équipe IT qui du coup garde la main sur ce qui est fait et comment c'est fait ?

Frederic:
Alors, c'est super intéressant comme question parce qu'on voit qu'il y a un peu de friction sur ces sujets-là. Alors d'abord, sur des grands groupes comme ça, l'IT elle a un pouvoir important, notamment sur les sujets de sécurité alors là il y a toujours deux manières de voir les choses, on peut les voir de manière positive ou négative. La manière négative l'IT elle va tout de suite dire non non mais c'est quoi ce truc c'est une boîte noire, je sais pas ce qu'il se passe derrière. J'ai mon stack j'ai mon legacy qu'est-ce que tu vas me mettre dans mon système quelle faille tu vas venir m'intégrer, et puis il y en a d'autres qui ont plutôt une démarche en disant le truc il audite ils font des pen tests ils mettent le paquet c'est quand même super robuste quelque part ça va nous décharger parce que c'est quand même des stacks qui arrivent qui sont déjà certifiés un stack comme Xeno c'est SOC 2, c'est SOC 3, c'est ISO c'est HIPAA, c'est RGPD bien sûr donc c'est un gros boulot pour un service IT notamment quand t'es des petites PME de te dire attends mais il faut que je sécurise tout mon stack donc là t'arrives on te livre un stack déjà super certifié super sécurisé. Et ça, c'est le bon côté. Mais quand même, pour répondre à la question, pas faire trop de disgression, c'est qu'en fait, malgré tout, le métier ne peut pas se permettre d'aller utiliser des outils qui ne sont pas certifiés par l'IT. Donc, c'est un peu un passage obligé. Là, je parle vraiment des gros corporate, je ne parle pas des startups ou des petites PME où on peut, tu vois, on peut faire un pont. Là, c'est OK, moi, je m'appelle Europe Assistance BNP, tout ça. Mais avant toute chose, il y a un prérequis, c'est que j'ai l'accord de la sécurité. Et de l'IT, et du service IT. Il y a ça. La deuxième chose qui fait très peur au service IT, c'est le Shido IT. Ça, c'est une plaie en entreprise. Le nombre de fichiers Excel avec des macros, mais... Si on regarde pourquoi le shadow IT finalement est apparu, c'est aussi parce que souvent, les services IT n'étaient pas assez rapides. Combien il y a de commerciaux, de data scientists, etc., qui ont développé leurs propres solutions sur leurs machines ? Ce n'est pas parce qu'ils ne voulaient pas impliquer l'IT, c'est parce qu'en fait, c'est trop long. Parce que tout le process de l'entreprise, quand c'est des grandes entreprises, tout ça est trop long. Du coup, l'idée, quand tu vas voir des services IT, c'est de leur dire aussi, on va te décharger de ça. On va te décharger parce qu'en fait, il y a de la complainte. Et d'ailleurs quand tu parlais avec les services IT ils en ont marre d'être un peu les boucs émissaires de ouais tout le monde se plaint parce que nous on produit pas et tout mais nous on a des règles de fonctionnement donc souvent ça rentre par les métiers parce qu'ils ont entendu parler du no code en disant ça va accélérer les choses on va pouvoir enfin délivrer des choses mais on doit avoir l'accord de l'IT donc là-bas aller renvoyer du côté de l'IT côté de l'IT on lui dit écoute t'as plein de gens dans l'entreprise qui ont envie de mettre en place dans Open Innovation et tout mais d'abord il faut ton accord alors là il y a peut-être des fois un peu de réassurance à faire mais on commence à savoir le faire on les rassure, ils ont fait et c'est là où la balle repart souvent du côté métier, je pense que là où des fois ça serait pas mal d'avoir la barre au centre ça s'engage que moins sur le sujet c'est qu'il y a quand même dans le no-code des sujets qui sont très IT pense à l'autodification par exemple la gestion des rôles quand on utilise des brokers de messages ou des choses comme ça, il y a un moment ça sera peut-être mieux que ça reste dans le service IT pour qu'il y ait une certaine forme d'homogénéité en horizontal dans tous les services de l'entreprise. Et là, il faut avoir le bon outil no code pour ça. Je pense que tous les outils no code ne sont pas faits pour être installés intra-entreprise. Parce que justement, il y a toujours un plus petit dénominateur. Et là, j'ai envie de dire, c'est presque le stack rêvé. T'as l'IT qui gère les points les plus sensibles de sécurité, de certification, etc. Et ensuite, chacun des métiers qui se concentre sur son métier. Et c'est là où le citizen développeur, il a son rôle à jouer.

Bruno:
Ok, mais donc les applications, au final, sont créées conjointement par l'IT et les métiers directement ?

Frederic:
Je dirais presque qu'idéalement, c'est le métier qui crée l'application sous la houlette de l'IT qui est là pour pousser en prod quand ils auront certifié que ça a été fait dans les règles de l'art. Et du coup, ça laisse une agilité incroyable parce que les métiers, qui mieux que le métier pour créer sa propre application il n'y a pas ce risque de transfert de savoir il y a des métiers, ils ne savent pas écrire des cahiers de décharge mais pourtant tu es bien obligé de le faire, même si tu n'es pas dans des cycles en V tu es quand même obligé à un moment de spécifier des choses donc ils ne savent pas faire, ça prend du temps et les techniques ne connaissent pas le métier donc ils doivent s'acculturer, c'est lourd alors qu'aujourd'hui tous ces outils sont en impour ouais.

Bruno:
Donc il n'y a pas une vocation à remplacer les devs. On peut rassurer tous les devs qui nous écoutent, qui ont une peur du no-code. C'est juste pour nous décharger. Moi, un exemple que je prenais souvent quand j'ai découvert Mec et Rtable, le premier usage que j'ai vu, c'était sur l'intégration, des API, notamment d'authentification. Il y avait tous les sujets d'intégrer, à l'époque, un Twitter, un Facebook, tous les SSO. En fait, Là, d'un coup, ça devient beaucoup plus facile d'aller prendre du contenu quelque part pour le mettre ailleurs, alors qu'avant, c'était une tannée à gérer tous ces trucs-là. En fait, tu faisais tout le temps la même chose. C'était tout le temps, ok, on refait une certification. C'était le cas plus possible. Le but, c'est effectivement, comme tu le disais très justement tout à l'heure, on a de plus en plus d'abstractions dans nos métiers depuis les années, 1960 à aujourd'hui. Ces outils no-code, c'est une nouvelle abstraction. Qui nous permet de faire plus de choses et nous concentrer sur la partie la plus intéressante de notre métier.

Frederic:
Moi c'est comme ça que je le vois et sachant qu'on peut toujours faire du low-code et de toute façon on est bien obligé. Il y a un moment je vois bien même dans les universités aujourd'hui, ils sont passés au low-code nous on a des partenaires chez Xano, on est avec des universités, on voit bien que maintenant on va apprendre même aux développeurs à utiliser dans leur boîte à outils l'IA, qui est quand même un gros sujet l'IA pour coder, tous les outils d'automatisation. Aujourd'hui mec, toi tu parlais de Zapier ou N8N par exemple que je trouve génial, et puis tous ces stack no code et il n'y a aucune raison aujourd'hui d'en avoir peur en tant que développeur et tout est à gagner, en tous les cas c'est comme ça que moi je le vois avec un profil tech en plus.

Bruno:
Mais c'est vrai que le... L'IA aujourd'hui, elle est extrêmement utilisée dans les environnements de no-code et de low-code parce que ça te permet effectivement de générer beaucoup de choses, ça permet d'énormément booster tous les services et toutes les apps que tu peux créer grâce à ça. Mais c'est vrai que je peux comprendre sur des populations de développeurs et de développeuses, notamment des gens qui viennent d'arriver dans le métier, qui avaient la perception que c'était un métier qui allait continuer comme ça pendant des années et des années et qu'ils étaient protégés, de se dire, attends, on a les IA génératifs qui nous attaquent d'un côté on a tous les gens qui nous disent qu'ils peuvent faire du code avec machin et puis là d'un coup maintenant ils peuvent aussi, directement créer des applications avec, un ensemble de services on peut comprendre que le métier se sente menacé du truc.

Frederic:
Je pense que tu as vraiment dit le mot qu'il fallait dire je pense que les codeurs et les développeurs c'est à dire on était dans un espèce de milieu protégé et on rigolait bien même des fois de créer nous-mêmes des outils qui remplaçaient les autres entre guillemets, on est un peu protégé genre dans tous les cas il faudra toujours des codeurs pour faire des outils voilà même si on crée des super outils moi j'ai vu arriver le début de la PAO par exemple tu vois où les imprimeurs ils ont commencé à flipper ils se disent il y a des mecs qui vont faire ça chez eux avec des t'as connu Calamus des trucs comme ça vraiment le début de la PAO, et ça n'a cessé d'arriver mais aujourd'hui moi j'ai parlé avec des gens des éditeurs par exemple ils ont très peur de l'arrivée de chat GPT qui peut écrire un magazine presque en tous les cas tant que t'as pas un contenu, donc tout le monde entre guillemets peut se sentir menacé peut-être pour une première fois c'est les développeurs qui se sentent à leur tour un peu menacés. Donc effectivement il y a un vrai sujet mais quoi une fois que t'es menacé tu fais comme un lapin pris dans des phares ou tu te dis bah tiens je vais commencer à apprendre à voir ce que ça peut m'apporter à moi voir comment je peux l'utiliser mon métier il va muter il va évoluer il a toujours évolué quoi alors c'était des vagues mais je veux dire, quand les mecs faisaient du C moi je me rappelle que les gens ils faisaient du C quand ils sont passés à C++ ils ont eu du mal à la logique objet ils n'y arrivaient pas je pense qu'il y en a qui ne sont jamais passés au C++ même peut-être en tout cas la programmation et puis après il y a eu la programmation web on va dire c'était un changement de paradigme un peu par rapport à des mecs qui habitent de faire des librairies tout d'un coup ils font des microservices, donc il y a toujours des évolutions voire un peu plus violentes que d'autres, à la limite de la révolution, j'aime pas, mais voilà. Je comprends qu'ils se sentent un peu menacés, mais s'ils commencent à l'utiliser, ils vont tomber amoureux du truc, je pense, en tous les cas. Mais t'as raison, il y a quelques jours j'étais à l'étranger et je suis tombé face à des développeurs, une des plus grosses boîtes de développement au monde. Ils ont des équipes de dingues par dizaines de milliers de développeurs, pour pas les citer. Et un développeur qui est venu me voir, il est les yeux dans les yeux, il m'a dit « Comment, quoi ? À moi, tu viens me dire que tu vas mettre du no-code, moi qui suis codeur ? » J'ai l'impression que j'insultais toute sa famille, quoi. Et là, je lui ai expliqué. Je lui ai dit « Attends, mais tu sais que... », tous les concepts de la programmation sont dans les outils no code en fait, peut-être tu perds moins de temps à rédiger du code, à débugger chaque point virgule et tout parce que t'as des briques déjà optimisées qui sont là, mais en fait ton métier reste le même, on aura toujours besoin de gens comme toi, tu vas peut-être évoluer sur certains outils, si t'as un jeune, il avait peut-être pas encore eu, vraiment jeune quoi il avait vraiment peut-être pas encore connu ces grands changements qu'il oblige mais que peut-être d'autres développeurs ont connu et se sont adaptés quoi, donc moi je crois qu'on peut, tous ces stacks c'est vraiment incroyable. Il y en a qui sont plus techniques, d'autres moins techniques. Choisis l'outil qui te parle le plus en fonction du besoin de ton client, du projet.

Bruno:
J'avais deux idées en même temps, mais du coup, celle par laquelle je voulais commencer à m'échapper, c'était sur... Non, écoute, elle est partie. C'est pas grave. C'est le fait qu'effectivement, je pense qu'il est plus que temps de réellement découper dans la tête des gens le métier de développeur et le métier de codeur, et de comprendre que certes le métier de codeur il y a des chances qu'il disparaît, il a plus de chances de disparaître que le métier de développeur et il faut bien, distinguer ces deux éléments-là et qu'au final si demain tu demandes à un développeur ou à une développeuse tu lui dis, bonne nouvelle, la semaine prochaine tu ne vas faire que écrire des lignes de code tu ne vas faire que pisser du code pendant 8h par jour toute la semaine tous ils vont te dire bah non en fait j'ai pas envie c'est pas ça mon métier, écrire la ligne de code c'est pas ça notre métier quoi.

Frederic:
Ouais et en plus et soyons honnêtes peut-être qu'on va te retirer une petite partie qui est le code parce que tu feras moins de code mais en même temps on t'apporte plein d'autres choses par exemple on t'apporte la capacité à faire du DevOps parce que tu vois avant dans une entreprise t'avais besoin d'avoir un DevOps dès que t'avais un peu d'archi t'as besoin d'avoir un DevOps Mais ces stacks-là, comme elles arrivent déjà configurées, t'as moins besoin de DevOps, donc tu vas être plus light. Donc un développeur pourrait, par exemple, dans une petite entreprise, prendre ça sur ses épaules et pourrait faire gérer la CICD parce qu'elle arrive avec le stack. Et même de l'IA, franchement. Moi, l'IA, taper des tonnes de livres et de faire du code pour recréer mes réseaux de neurones et tout ça, franchement, il faut investir du temps pour le faire. Mais aujourd'hui c'est presque à la portée de tout le monde de commencer à faire un peu de deep learning ou je sais pas quoi t'as les outils même visuels parce qu'on parle de no-code mais on pourrait parler aussi de no-code dans l'IA où t'as beaucoup d'outils en fait qui te permettent de créer tes propres LLM, tes propres chatbots, tu vois t'es avec l'arrivée du MCP, c'est encore un sujet et tout, mais aujourd'hui c'est à la portée d'un développeur tu peux devenir développeur IA, DevOps, gérer le développement de l'appli et en plus t'approcher des métiers et all-in-one. Donc... Il faut voir aussi le bon côté des choses. Ce n'est pas que négatif, je t'enlève un truc, c'est aussi que je t'en apporte plein d'autres. Moi, je trouve que c'est leur apporter une vraie opportunité. Et puis, c'est aussi apporter quelque chose à tout l'écosystème. Parce que là, nous, en tant que développeurs, on est là aussi pour servir une cause. Pour servir une cause de créer des outils, créer des produits, créer des solutions, apporter des réponses. Il y a les no-code for good, par exemple, qui adorent se concentrer sur les projets good. Tu vois, on ne parle pas beaucoup, mais dans le milieu associatif, le no-code, c'est génial. Parce qu'en fait, ça coûte beaucoup moins cher, c'est plus rapide. Souvent, les associations, elles n'ont pas d'argent, elles ne peuvent pas avoir de CTO, elles ne peuvent pas avoir trop de développeurs, etc. Ça apporte beaucoup de choses à beaucoup de monde, quand même.

Bruno:
Oui, carrément. Pour terminer, sur une partie peut-être un peu plus prospective, parce que tu es effectivement aussi anciennement développeur, tu es maintenant dans l'industrie du no-code et du low-code. Je serais curieux d'avoir ton avis sur la disparition éventuelle ou projetée du concept même de code, moi il y a quand même une il y a un avenir que je vois que j'ai déjà évoqué quelques fois à ce podcast et à de plus en plus de gens autour de moi, c'est de se dire que au final si tu prends aujourd'hui n'importe quel API ou n'importe quel, service web qui existe t'as une requête HTTP qui arrive quelque part où t'as du code qui va s'exécuter pour aller chercher différentes informations dans différentes bases de données, te faire un, agrégat de tout ça et te construire une page HTML pour l'envoyer en réponse au client qui a fait la demande. Qu'est-ce qui empêche de se dire que dans un an, ta requête HTTP arrive directement sur une IA qui comprend avec l'URL qui a demandé quel endpoint, qui comprend qui a fait la demande et donc va chercher. C'est une IA qui sait que l'info a tel endroit, que les users sont là, que le listing client, le listing, le catalogue produit, il est à tel endroit. Tu vois qu'il a accès à toutes les bases de données, à toutes les sources d'informations, et qui va d'elle-même te générer du coup la page HTML et va te pousser le HTML, en sortie pour être lu par un browser. Et qu'en fait dans toute cette ligne-là, du coup t'as plus de code qui a été réellement écrit mais t'as une IA en fait qui exécute et qui te devine au final le contenu.

Frederic:
Alors c'est une bonne question, je ne m'attendais pas forcément mais alors, La disparition du code, ça dépend de quoi on parle. Déjà, le code, il faudra le définir, ce qu'on appelle le code. Pour moi, le code, c'est un vocabulaire et une grammaire. D'ailleurs, moi, je me rappelle ma première année d'études d'ingénieur sur le code. On avait des cours de code et le prof a commencé à dire, voilà, il y a une syntaxe, il y a un vocabulaire et il y a une grammaire. C'est ça du code informatique, c'est comme un langage, un langage humain. Donc, je pense que ça, dans tous les cas, ça devra continuer à exister. C'est un protocole. Pour appeler un protocole en réseau ça je pense que si on dit que le code c'est un langage je pense que maintenant peut-être que demain l'IA va créer un langage optimum il y a quelques années on avait fait des tests pour faire parler des IA et on s'était rendu compte que les IA avaient créé leur propre langage pour communiquer entre eux, il y a de fortes chances je vois pas pourquoi ça arriverait pas demain en disant mais attends Java c'est même le code interprété, nous on a fait du code lisible mais pourquoi que les machines auraient besoin d'un code lisible au final, donc là où je suis d'accord je pense qu'il va se créer un truc. Qui va nous dépasser qui vont faire que les machines vont trouver un mode de, communication entre elles là où je te rejoins complètement c'est si tu dis que le code c'est des routines, qu'on a créé à l'avance et non des routines comme tu dis un peu prédictivement montées et là je suis d'accord avec toi je pense qu'il y a des chances qu'on arrive vers ça, mais quand même c'est un peu comme l'IA c'est de l'apprentissage supervisé il y a un moment il faudra quand même superviser parce qu'il y a quand même des métiers et de la connaissance humaine etc en tous les cas pour pas mal de temps je sais pas si nous on verra ça, mais là où je suis assez d'accord il y a des chances qu'à un moment on arrête d'écrire du code avant, on va dire en prévision des besoins mais qu'on apprenne à des IA plutôt à communiquer entre elles via des langages qu'on pourrait appeler pour le coup de code, qui pourraient faire effectivement soit en prédictif soit en temps réel avec la vitesse de la lumière, sur du quantique et tout ça en plus donc tout ça va accélérer et oui je partage cette vision je partage cette vision j'espère qu'on n'a pas fait peur.

Bruno:
À trop d'auditeurs et auditrices avec cette projection. En tout cas, ce que tu disais aussi tout à l'heure est très juste, c'est maintenant qu'on accepte qu'il y a un métier qui va changer, on a deux options. C'est soit on reste là et essayer de préserver autant qu'on peut notre métier le temps qu'on peut, soit on embrasse le changement et on se dit, ok, qu'est-ce que je peux faire dans ce contexte-là ? Et on fonce en apprenant à maîtriser les IA gentils, les frameworks qui vont avec, les outils no-code, pour embrasser un peu ce que...

Frederic:
Franchement, on va s'éclater, parce que là, on a des panoplies sous la main en tant que développeur. C'est incroyable, pour créer des choses incroyables. Je comprends la peur, on est tous, comment dire, on a tous nos propres peurs. Je ne sais pas si tu as lu le bouquin The Singularity is Near, sur la théorie de la singularité, qu'en 2045, l'intelligence de la machine dépassera l'intelligence humaine. Et Ray Kurzweil, qui travaille chez Google, avait écrit ce livre, je crois, dans les années 80, 90, et il l'a vu assez juste, et là, il est en train de réécrire un bouquin, et je crois que le livre s'appelle La singularité is nearer. Ça fait tellement plus vite que prévu. Et c'est génial, je vous invite vraiment à le lire. Évidemment, on peut le lire d'une manière où ça fait peur. En même temps, les machines, c'est nous qui les avons créées. Mais. Oui, une vraie opportunité pour les entreprises, et là je le vois à travers tous les projets corporate dans le no-code no-code slash IA, moi j'ai pas trop envie de les séparer clairement, et une vraie opportunité pour tous ces développeurs d'aller plus loin et peut-être se séparer en plus d'un truc qu'ils faisaient, il y en a toujours qu'à d'or mais finalement ils aiment peut-être pas forcément tant que ça, mais t'as raison quand tu dis, quand tu vraiment t'appuies le fait que codeur et développeur c'est pas forcément le même métier et je pense que c'est vraiment le sujet, on avait Peut-être que jusqu'à présent, on n'avait pas tant séparé les choses. On avait plus séparé l'architecte logiciel du développeur. Là aussi, c'est un atout le no-code parce que finalement, ça permet à des développeurs de devenir aussi des architectes. Tu as une vision un peu plus high-level. Donc tu vois, ça apporte plein de trucs.

Bruno:
Merci beaucoup Frédéric pour cette discussion. J'aurais deux dernières questions pour toi qui sont les questions rituelles du podcast. La première, c'est est-ce qu'il y a un contenu que tu serais partagé avec l'ensemble des auditeuristes ?

Frederic:
Moi j'aime bien les bouquins, j'en ai parlé du leak sur la singularité, Fall in love with the problem and not the solution de Uri Lévin, qui est le fondateur de Waze, je le trouve super intéressant. Ce que je trouve intéressant c'est des livres comme The Pragmatic Programmer, je sais pas si tu as lu, culte, on voit qu'en fait c'est un peu comme le DDD en fait, c'est des livres qui n'ont pas été forcément écrits dans l'univers du no code pour le no code bien sûr, c'est des livres qui datent de... Tu apprends ça quand tu commences à coder et en fait t'as l'impression que c'est presque des visionnaires, tu pourrais les réécrire dans ça et au moins il y a un livre que j'aime bien d'un français c'est Jean-Marie Dru qui avait écrit un livre, ça s'appelle Distruption c'est lui qui a inventé, tu connais sûrement le terme distrupter, quand il dit il faut que tu distrupes ton métier c'est lui qui a réinventé, on va dire remis à jour ce terme de destruction, et je trouve ça intéressant parce que c'est une méthode pour finalement toujours te reposer la question de voilà je suis dans ma zone de confort comment je distrute mon métier, comment je le challenge comment je me réinvente, donc voilà peut-être s'il y avait un peu de lecture ce serait ces contenus là canon.

Bruno:
Et bien écoute on mettra bien évidemment des liens en description pour que les gens puissent retrouver ça facilement, et dernière question qui est la question la plus importante de ce podcast est-ce que tu es plutôt espace ou tabulation ?

Frederic:
Alors ça c'est une vraie question alors est-ce que cette question elle a encore, alors moi je suis plutôt tabulation parce que sinon comme je suis très petit travailleur fourmi je serais capable de passer des heures à faire des espaces, alors moi ce que j'aime bien dans ta question c'est qu'aujourd'hui est-ce que finalement il ne faudrait pas la remettre au goût du jour, aujourd'hui on travaille beaucoup avec des shortcuts, on a des raccourcis partout alors finalement est-ce que ce serait pas, est-ce que tu es plutôt contrôle espace ou contrôle tabulation et là je dirais plutôt contrôle espace parce que moi j'ai plein d'outils, qui se déclenchent sur mon contrôle espace Très bien.

Bruno:
Top, merci beaucoup Frédéric Avec plaisir.

Frederic:
Merci pour l'invitation.

Bruno:
Et merci à tous d'avoir suivi cette discussion On a un métier qui est en pleine évolution et c'est une très bonne nouvelle il y a plein de changements qui sont à adresser et à faire, on va pouvoir faire encore plus de choses que ce qu'on arrivait à faire jusque là donc embarquer dans cette aventure formidable, si vous venez d'arriver dans le métier de développeur ou de développeuse, félicitations parce que vous êtes au début d'une vague. Qui va être colossale, donc amusez-vous bien, éclatez-vous et apprenez, il y aura encore plein de choses à faire. Je vous remercie aussi comme toujours de partager ce podcast autour de vous. Je vous souhaite une très bonne fin de semaine. Je vous dis à la semaine prochaine et d'ici là, codez bien.