Bubble : Ruptures et Possibilités

Bruno — C'est quoi être dev ? Comment pourrait-on quantifier ce métier ? Clairement, il ne s'agit pas du nombre de lignes de code écrites. Nous le savons, la meilleure ligne de code, c'est celle que l'on n'écrit pas. Mais si on réduit le nombre de lignes à son strict minimum, à quel moment ce n'est plus du dev ? Le dev, c'est avant tout de la conception. Traduire un besoin en solution technique, quelle que soit la technique utilisée. Mais alors, dans quelle bulle vit-on en tant que dev, va-t-on arrêter de coder ? Et surtout, ne serait-il pas temps de se pencher sur un nouveau genre de framework ? Pour répondre à ces questions éclatantes, je ne reçois pas Jérôme Kerviel, mais il s'y connaît. En bulle, Emmanuel, bonjour.

Emmanuel — Bonjour.

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

Emmanuel — Oui, donc je m'appelle Emmanuel Strachnoff et je suis fondateur de Bubble, qui est probablement la première plateforme de NoCode qui s'est lancée en 2012 aux Etats-Unis. Donc j'ai lancé ça avec mon associé il y a maintenant 12 ans et je fais tourner ça depuis 12 ans. Français d'origine, même si j'ai quitté la France il y a un peu plus de 17 ans maintenant. J'ai un peu vécu en Asie pendant 4-5 ans, donc assez longtemps quand même, avant d'aller aux Etats-Unis. Je me suis installé aux Etats-Unis maintenant, mais très souvent à Paris. Et ravi d'être là.

Bruno — Écoute, ravi de te recevoir aussi. Qu'est-ce qui a donné l'envie de créer un environnement no code ? Parce qu'il y avait déjà beaucoup de techno qui existait. Pourquoi faire une techno qui n'utilise aucune techno au final ?

Emmanuel — Parce que le problème qu'on a identifié, c'est que même si les technologies ont beaucoup évolué, et que c'est vrai que depuis les débuts des années 80, en fait, les langages de programmation sont de plus en plus accessibles, c'est-à-dire qu'on est passé des 0 et des 1 à des langages avec des abstractions de beaucoup plus haut niveau qui font que c'est beaucoup plus facile de programmer, ça prend beaucoup moins de temps à apprendre, le nombre de programmeurs n'a pas changé de façon fondamentale. C'est-à-dire qu'on est toujours sur un très petit pourcentage de la population qui s'est codée, et dans un monde où quand même la création de choses, et puis d'un point de vue plus théorique, la création de valeur passe essentiellement par la technologie, c'est un problème que ce soit juste 1 ou 2% de la population qui puisse le faire et donc nous on voulait résoudre ça, il y a beaucoup de gens qui ont vu ce problème là, on n'est pas les premiers à l'avoir vu, quand on s'est lancé d'ailleurs la façon dont les gens pensaient qu'on allait résoudre ce problème c'était par l'éducation donc il y avait en France, François Hollande parlait du plan codage à l'école en 2014-2015 aux Etats-Unis il y a eu beaucoup d'initiatives pour, enseigner le code, Code Academy qui était une start-up lancée à New York pour apprendre le genre à coder, était d'une certaine façon une façon de résoudre ce problème là et nous on n'a jamais pensé que ça marcherait parce que je pense qu'in fine tout le monde n'est pas fait pour avoir le degré d'attention je sais pas ce qu'on veut dire d'introversion pour regarder des caractères sur un écran noir et vérifier qu'on n'a pas oublié une virgule parce qu'in fine le code c'est ça et donc on s'est dit changeons les outils à la place et donc c'est devenu un outil, un outil visuel et c'est pas du tout. Nouveau c'est à dire que le passage ce qui fait que l'informatique est devenue l'informatique aujourd'hui c'est le passage d'MSDOS à Windows et d'Apple qui a introduit l'interface graphique donc ça a été prouvé, de multiples fois qu'une interface graphique démultiplie l'accessibilité d'un outil et donc on voulait faire la même chose sur le code là aussi on n'était pas les premiers nous je pense que notre innovation est vraiment sur l'exécution ce qu'on a bien fait c'est l'exécution on a aussi attendu suffisamment longtemps pour que les technos soient, pour rendre ça possible. Il y a plein de gens qui, depuis les années 80, ont essayé de créer une interface graphique au-dessus du code. Apple avec HyperCard est probablement la première tentative à la fin des années 80. Jusqu'à présent, ça n'a pas marché au sens où en 2012, et j'ai envie de dire encore aujourd'hui, c'est pour ça que je pense que même si la boîte marche bien, on n'a pas encore réussi à faire ce qu'on... On a juste à 1% ou 5% du travail parce qu'aujourd'hui, les gens apprennent encore beaucoup du code à l'école et je pense qu'ils ne devraient pas. Je pense que les gens qui aiment coder devraient apprendre le code de toute façon quand on aime quelque chose on le fait mais je pense qu'il y a beaucoup de gens aujourd'hui qui se forcent un petit peu à apprendre ça parce qu'en fait fondamentalement ce qu'ils veulent faire c'est créer des produits et pas taper du code et donc ces gens là je considérerais que j'ai, réussi avec Bubble quand ils n'apprendront plus de code et qu'ils feront j'espère du Bubble mais si c'est pas du Bubble un autre outil à la limite peu importe mais un outil visuel.

Bruno — On a fait juste avant le compilé de l'épisode avec Alexis tu dis qu'effectivement il y a beaucoup de gens qui se penchent sur le métier de codage et qu'il y a un manque de codeurs par rapport aux noms de gens qui veulent créer des produits. Est-ce que tu savais qu'en France il y a plus de millionnaires que d'ingénieurs ?

Emmanuel — Ça m'étonne pas. Je ne savais pas mais ça m'étonne pas.

Bruno — Donc c'est plus difficile de devenir ingénieur en France que de devenir millionnaire. J'ai toujours trouvé ça.

Emmanuel — Mais c'est assez fascinant que malgré, les technologies qui sont de plus en plus faciles parce que de faire du Rubien Rails ou du React aujourd'hui c'est quand même beaucoup plus facile que de faire du C il y a 20 ans, les efforts à l'école, que ce soit dans les universités, l'école 42, le contenu en ligne, les tutoriaux YouTube, enfin les tutoriels YouTube et tout ça, la proportion de développeurs n'a pas augmenté. C'est quand même assez fascinant.

Bruno — Mais aussi, malgré toutes ces couches d'attractions supplémentaires qu'on a ajoutées, est-ce qu'on peut vraiment dire que le métier de développeur ou développeuse s'est simplifié ? Parce que en fait, tu regardes...

Emmanuel — Oui, évidemment.

Bruno — Bah oui mais en même temps on fait des choses qui sont beaucoup plus complexes qu'avant, on a des volumétries, la complexité on l'a reproduite ailleurs.

Emmanuel — Oui, sur le design d'application peut-être, mais je pense que c'est beaucoup plus facile d'être un développeur aujourd'hui que ça l'était il y a 20 ans.

Bruno — Tu penses que le métier est plus accessible à tous, enfin à plus de monde ?

Emmanuel — Oui, mais dans les faits, il n'y a pas beaucoup plus de monde qui le fait. Mais quand il s'agissait d'écrire de l'assembleur, c'est quand même beaucoup plus compliqué que de faire une app en React aujourd'hui. Et Bubble en partie encore plus, mais c'est un outil un peu différent.

Bruno — J'avais vu une conférence il y a longtemps dont j'ai déjà parlé plusieurs fois sur ce podcast qui était intéressante, qui parlait effectivement de l'évolution des langages et l'intervenant mettait le doigt un peu sur le fait que, il y a aussi le fait que ceux qui créent les nouvelles technos et les nouveaux langages ont appris ce métier-là en souffrant et se disent qu'il est normal que ceux d'après souffrent aussi.

Emmanuel — Et en.

Bruno — Fait perpétuent une façon de faire sans forcément aller le chercher une nouvelle façon de construire des applications on essaie de garder no if no else no while no book.

Emmanuel — Je sais pas si c'est on a souffert donc les oeufs vont souffrir ou c'est plus, on a cette compétence et on veut un peu la garder pour nous personnellement mais c'est un peu la même chose mais je pense tout à fait et d'ailleurs alors maintenant le no code a suffisamment de traction pour que, beaucoup de gens s'y intéressent en particulier les gens de la Silicon Valley mais en 2012 quand on s'est lancé à l'époque c'était vraiment j'ai envie de dire un peu le pic, de la nouvelle génération de développeurs qui voulaient lancer des sas et des choses comme ça, personne ne s'intéressait à ce qu'on faisait dans la Cicconelle nous on a levé de l'argent très tard on a bootstrapé, on a autofinancé le business pendant 7 ans mais on a eu des conversations parce qu'il parlait avec des investisseurs, jamais personne n'a été intéressé par ce qu'on faisait pendant les 7 premières années.

Bruno — Parce que pourtant il y a beaucoup de projets qui sont créés grâce à ce type d'outils.

Emmanuel — Oui mais c'était après enfin, les outils qui étaient créés les start-up nous en plus on était vraiment sur un marché où les gens lancent des boîtes sur nous donc on a beaucoup de start-up qui se créent sur Bubble ça reste aujourd'hui le use case principal, ces gens là sont pas des gens non plus qui lèvent de l'argent donc on est assez anti Silicon Valley par pas mal de côtés et le fait qu'on soit lancé à New York était une bonne chose à San Francisco ça aurait été difficile il y a eu beaucoup de résistance de l'écosystème pour ce genre d'outil pendant longtemps.

Bruno — Au final en fait avec Bubble tu crées une abstraction supplémentaire parce que tu parles beaucoup de nos codes mais en fait il y a quand même beaucoup de codes dans Bubble.

Emmanuel — Le code que nous on écrit oui ça évidemment il y en a beaucoup il y a aussi la plateforme extensible juste pour expliquer un petit peu ce que c'est d'un point de vue, d'un point de vue assez simplifié c'est assez simple en fait l'idée c'est qu'une application c'est trois choses c'est un design donc généralement une interface utilisateur des workflows il faut de la logique et une base de données. Il y a quelques applications qui n'ont pas de base de données, mais c'est quand même très rare. La plupart du temps, il faut au moins enregistrer la base d'utilisateurs pour que les gens puissent créer un compte login, logout. Et donc, nous, on a créé une interface graphique, donc une abstraction graphique qui permet aux gens de créer son interface graphique. Alors ça, c'est la partie la moins innovante, puisque Visual Basic faisait déjà ça des années 90, même Front Page, où en gros, on dessine son application en mettant les différents boutons, images, les formulaires où les gens peuvent taper des choses, les inputs comme on dit en anglais la partie workflow qui est la partie un peu plus innovative. De notre côté où là où Visual Basic on double cliquait sur un bouton pour taper du code pour dire ce qui se passait sur un click event concrètement ça c'est la partie qu'on a transformée avec un système de workflow visuel on peut dire quand l'utilisateur, clique sur un bouton enregistrer l'utilisateur envoyer un email charger une carte de crédit et on a pré-codé ces cases là et après la donnée ça ressemble à un petit variable c'est à dire qu'on définit les différents champs et ses différentes tables. Et donc, on ne peut pas créer... Je parle des éléments sur la page et les actions élémentaires dans les workflows. Par définition, on ne peut pas toutes les créer nous parce qu'il y a des choses où on ne peut pas tout faire nous-mêmes. Et donc là, on permet aux gens d'étendre la plateforme. Donc, la plateforme est extensible par du code. Donc, oui, il y a du code sur Bubble. Dans le fait, c'est 1% de nos utilisateurs qui vont écrire du code. Et après, il y a une marketplace où les gens qui ne savent pas coder peuvent acheter ou utiliser gratuitement selon ce que veulent faire les codeurs sur la plateforme s'ils veulent le vendre ou le rendre open source. Donc il y a effectivement du code, mais pour 99% d'utilisateurs, il n'y a pas de code dans Mabel, non.

Bruno — D'accord. Donc toi, tu te qualifies vraiment comme no code, tu ne dirais pas low code ?

Emmanuel — Oui.

Bruno — Ok.

Emmanuel — C'est un peu ambigu, parce qu'on permet aux gens de coder, donc il y a du code, mais par contre, pour les gens qui n'utilisent pas ce système de plugin, c'est vraiment no code. Ce qui est très important, parce que dès qu'on retombe dans le low code, on s'adresse à des développeurs. Alors que nous, on est vraiment pour des gens non techniques. C'est-à-dire que je pense qu'on a du mal à savoir, mais on fait régulièrement des petites études où on a nos utilisateurs pour le niveau technique. Je pense qu'il y a 80% de nos utilisateurs qui n'ont jamais écrit une ligne de code. 10% qui ont dû prendre un cours de code à l'école et 10% qui sont des vrais codeurs.

Bruno — J'ai eu le cas dans mon parcours de croiser des gens issus plutôt d'écoles de commerce, business school et autres, qui avaient quand même une certaine impétence. Il y a quelques heures, je me disais toi t'aurais fait un bon développeur ou t'aurais fait une bonne développeuse bah c'est notre marché ça est-ce que tu penses que avec Bubble t'es aussi une, une première marche pour ces gens là en fait pour se dire bah tiens maintenant est-ce que je pourrais pas aussi aller creuser un peu plus de JS ou de Python on.

Emmanuel — En voit beaucoup, on voit beaucoup de gens qui font ça en fait qui commencent sur nous et qui à un moment commencent à vraiment aimer ça, et qui souvent à cause du système de plugin en fait parce qu'à un moment ils veulent créer une action encore une fois qu'on a pas et qui est pas disponible sur la marketplace plutôt que de trouver un codeur je vais le faire moi-même et du coup qu'ils rentrent dans le code et c'est très bien. Encore une fois, si les gens aiment coder, qu'ils codent. Moi, ce que je dis, c'est que les gens qui n'aiment pas forcément coder mais qui ont besoin de créer des choses ne devraient pas coder.

Bruno — Donc, tu parlais tout à l'heure du fait que la démocratisation du code, c'est peut-être pas le chemin à suivre, ou en tout cas le seul chemin à suivre, mais au final, avec ta plateforme, tu permets aussi de démocratiser ou de faciliter l'accès au code.

Emmanuel — Oui, mais pour une petite partie de nos utilisateurs.

Bruno — C'est quelques pourcents. Ce n'est pas le but principal.

Emmanuel — Ce n'est pas le but principal. Je pense que c'est assez ineffical de réécrire du code. Par exemple, si on s'agit de créer une marketplace, genre un Airbnb quelconque, je pense que Bubble va prendre à peu près dix fois moins de temps. Donc même si on sait coder, j'ai envie de dire que c'est un peu dommage d'utiliser du code juste l'art pour l'art parce que c'est, in fine, le plus tôt on peut lancer le produit, le moins cher ça coûte à produire, qu'on le fasse soi-même parce que le temps d'une personne a de la valeur ou en payant quelqu'un pour le faire. Et après, ça va plus vite pour itérer sur le feedback des utilisateurs donc je milite quand même même si on aime coder pour ne utiliser le code uniquement pour les choses nouvelles, et là où je pense qu'on peut avoir le plus grand impact en tant que plateforme c'est que si at scale ce que j'espère va arriver c'est que les gens arrêteront de réécrire du code pour des choses ce qui existe déjà avec l'open source l'open source permet d'éviter de la réécriture de code cela dit le problème de l'open source c'est que c'est pour d'autres codeurs donc le marché est assez petit, mais si on crée un monde où les gens ne créent du code que pour des nouvelles choses et quand c'est pas des nouvelles choses utiliser une plateforme visuelle, espérons la nôtre, qui permet de créer les choses beaucoup plus vite, on aura un impact énorme, parce que on va libérer beaucoup de temps de cerveau de gens intelligents pour travailler sur des problèmes nouveaux.

Bruno — C'est un truc que je trouve toujours... Je trouve qu'il y a une espèce d'ambivalence dans le monde des développeurs et développeuses qui est assez intéressante, c'est qu'on déteste refaire deux fois la même chose, c'est-à-dire qu'on a une tendance à se dire, si je fais deux fois la même chose je préfère passer une semaine à essayer d'automatiser ce truc-là.

Emmanuel — Parce que tous les codeurs sont des gens pareils.

Bruno — Complètement. Et donc on a tendance à... Tout ce qui est phénoménal baller plate, quand on lance un projet, c'est des trucs qui sont hyper casse-pieds, on n'a pas envie de les faire et donc on a nos librairies, on a nos frameworks qui existent, mais il y a un moment, et que j'arrive pas difficilement à identifier parce que quand tu parles de WordPress à un développeur il va te dire moi je veux pas de WordPress je veux faire les choses moi-même oui mais à quel moment en fait tu décides qu'il y a des choses que tu veux pas faire et des choses que tu veux faire quand même même si pourtant tu pourrais ne pas les faire et te consacrer à quelque chose je trouve qu'il y a une espèce de frontière bizarre je.

Emmanuel — Pense que c'est assez personnel sur les différentes personnes mais oui je vois tout à fait quoi tu parles.

Bruno — Et donc avec Bubble en fait c'est quoi c'est une nouvelle couche d'attraction c'est un nouveau framework qui est encore plus t'as encore plus de baller plate que ce que t'avais quand tu lançais un Symfony c'est ça.

Emmanuel — Les deux parce que c'est pas mutuellement exclusif c'est ça oui, moi je vois ça vraiment comme c'est une abstraction au dessus de HTML, JavaScript et CSS en gros, on n'est pas sur on utilise React maintenant donc on pourrait dire au dessus de React mais à la limite peu importe mais sur la techno fondamentale du web qui est vraiment le HTML le CSS et le JavaScript. Pour le front-end donc oui on a une couche au-dessus on est d'ailleurs je pense beaucoup plus proche du JavaScript que JavaScript est proche de l'assembleur parce que les concepts du JavaScript ça va être ou d'HTML ça va être un div sur la page ou des choses comme ça, sur Bubble ça sera un bouton mais en fait la différence entre un div et un bouton est assez faible je pense que le fait de l'appeler un bouton fait une énorme différence pour l'utilisateur en particulier quelqu'un de non technique parce qu'un div Qu'est-ce qu'ils vont en faire ? Un bouton, ils savent ce que c'est. Et c'est un peu l'idée fondamentale de Bubble, c'est d'utiliser des concepts que les gens connaissent parce que tout le monde aujourd'hui, et quasiment tout le monde est ce qu'on dit en anglais « digitally native » parce que ça fait 20 ans qu'on utilise des sites internet pour réserver un appartement sur Airbnb, un hôtel, un billet de train, enfin toutes ces choses-là. Donc les gens, en fait, même s'ils ne s'en rendent pas compte, la plupart des gens ont été formés pour penser en termes produits et savent ce que c'est qu'un élément bouton, un élément carte ou des choses comme ça à mettre sur une page. Mais encore une fois, on est beaucoup plus proche du JavaScript que le div est proche des 0 et des 1 qui est, in fine, ce que le processeur va comprendre. La raison pour lesquelles les développeurs traditionnels, les codeurs ont un peu de mal avec ces c'est la rupture en fait entre ce que je dirais en anglais text-based donc textuel, donc c'est des caractères et du code généralement sur un écran noir ou blanc selon les préférences des gens, et une interface graphique et du coup les gens voient une rupture là ce qui fait que les gens pensent que le no-code et le code sont très éloignés mais encore une fois je pense que nous ce qu'on fait, et le no-code façon bubble parce que le no-code maintenant est un espace assez vaste, il y a quand même beaucoup d'outils différents mais le docode façon Bubble, et encore une fois c'est de la programmation, c'est juste pas avec du code mais avec la souris, et encore une fois très proche finalement très proche des technos web que les gens utilisent aujourd'hui pour créer des web apps.

Bruno — Et cette rupture en fait ce que tu présentes comme une rupture c'est revenir à ce que t'évoquais tout à l'heure une volonté de préserver un peu son précaré, tu vois ça comme une.

Emmanuel — Je pense oui Je me rappelle dans les années, c'était peut-être 2013, 2014, on voyait des outils qui sortaient sur Producted pour commander un café par la ligne de commande, enfin des trucs totalement débiles entre nous, mais qui étaient assez représentatifs de ce fantasme de la ligne de commande. C'est un peu moins vrai maintenant, mais dans les cafés, en particulier aux Etats-Unis, à San Francisco, où tu voyais quelqu'un taper du code, les gens disaient « waouh, il est super smart, qu'est-ce qu'il fait ? » Alors qu'en fait, la personne ne fait pas forcément des choses très profondes. Il y avait une certaine fascination pour le code. Barack Obama, on le voyait avec une casquette code.org, qui est une ONG aux Etats-Unis pour enseigner le code. Il y avait une vraie fascination pour ça. C'était vraiment « waouh, Barack Obama a écrit du JavaScript. » et du coup oui je pense que cette fascination fait qu'il y a un côté un peu protecteur des codeurs collectivement qui voulaient garder ça mais c'est un, accident de l'histoire qui va pas durer.

Bruno — Ce qui est.

Emmanuel — Déjà moins vrai d'ailleurs.

Bruno — Ça me fait penser à il y a quelques jours, quelques semaines je crois que j'ai vu passer une vidéo sur TikTok d'une espèce de concours, sur Excel et en fait les gens sont intégralement au clavier, ils n'utilisent jamais leur souris, donc ça fait un bruit pas possible du coup mais ils font un nombre de trucs purement au clavier et il y avait quand même une espèce de dire waouh quand même ils font tout au clavier c'est un peu, tu vois ils n'utilisent pas la souris c'est ouf mais en fait c'est quand même vachement pratique la souris c'est une super invention quoi.

Emmanuel — C'est que Xerox je crois qu'a fait ça encore une fois je pense que Windows et Macintosh c'est ce qu'a fait l'informatique moderne aujourd'hui et sur les téléphones, l'iPhone et Android, mais l'iPhone d'abord, principalement de mettre une interface graphique et d'avoir des accès, des méthodes d'input intuitives et donc la souris en particulier a un impact énorme sur les choses et démultiplie la démocratisation des outils Ce.

Bruno — Que j'évoquais un petit peu en intro c'est que le métier de développeur c'est au final, c'est pas uniquement une question des lignes de code tapées c'est avant tout une capacité à traduire, un besoin une demande, enfin on peut l'exprimer comme on veut en une solution technique ce que tu permets effectivement de faire avec Bubble donc exclusivement la souris si on a envie, donc se pose effectivement la question de est-ce que c'est être développeur que d'utiliser Bubble ou pas mais se pose aussi la question de, En fait, si on tire le trait, tu as parlé tout à l'heure de front page, de Visual Basic et compagnie, la fameuse époque des WYSIWYG, où les développeurs ont tendance à dire « Ouais, mais en fait, c'est du code pas propre qui est généré.

Emmanuel — » Oui, mais ça, je l'entends encore aujourd'hui avec Bubble, ça.

Bruno — Mais parce que ce que je trouve intéressant avec l'approche de Bubble, c'est qu'au final, t'es pas tant que ça, t'es pas sur de la génération de code, en fait. Au final, tu génères pas de code.

Emmanuel — Non, c'est interprété, c'est pas compliqué. Mais j'ai envie de dire, c'est un détail...

Bruno — De l'histoire.

Emmanuel — Non c'est pas ça mais c'est un détail qui ne devrait pas être important pour nos utilisateurs il est possible qu'un jour on a vers la compilation parce qu'il y a des avantages à compiler c'est beaucoup de boulot et on ne fait pas tout de suite mais on ne génère pas de code cela dit à un point de vue macro je pense qu'il y a trop de lignes de code qui sont créées dans le monde, chaque ligne de code est un asset c'est un actif mais un passif aussi c'est à dire qu'après il faut la maintenir donc moins il y a de code mieux c'est.

Bruno — Est-ce que les gens qui utilisent Bubble, se qualifie de développeur est-ce qu'il y a une guerre de terminologie.

Emmanuel — Un peu un peu oui oui alors il se définit clairement développeur après il s'appelle on a un joker en fait pour la communauté parce qu'on a une communauté assez forte où les gens s'appellent des bubblers qui est une façon un peu d'éviter le problème là, ce problème là parce qu'ils pensent clairement qu'ils sont des développeurs des créateurs d'applications, mais par contre ils ne sont pas des codeurs moi d'ailleurs Notre thèse fondamentale C'est que développeur et codeur C'est deux choses différentes Développer c'est créer des applications Quelle que soit la plateforme Codeur c'est de mettre ses mains sur un clavier et de taper du code Ce n'est pas la même chose, Mais c'est nous qui le disons Le monde ne voit pas forcément les choses De cette façon encore On a encore du travail d'évangélisation à faire, Généralement quand les gens disent développeur On imagine des codeurs Du coup nos utilisateurs sont parfois un peu embarrassés parce que s'ils s'appellent développeurs mais qu'ils ne savent pas coder avec les gens les tests sur code ça n'a pas marché donc ils s'appellent debubbleurs mais, créer un nouveau métier. Et ça, c'est quelque chose qu'on a déjà réussi à faire parce qu'on a un écosystème maintenant assez fort de bubble... Ou alors, il s'appelle Bubble Developer, d'ailleurs. Bubbler ou Bubble Developer. Mais les développeurs bubble qui ont un métier maintenant, où il y a des gens qui recrutent déjà en tout ça, ça, on a créé une nouvelle catégorie de métiers. Il faut juste maintenant la faire suffisamment grandir et changer les esprits pour qu'on ne se batte plus sur la terminologie.

Bruno — Mais déjà, qu'on parle de développeurs bubble parce qu'au final, on parle de développeurs React, de développeurs...

Emmanuel — Voilà. ça on a ça déjà ça.

Bruno — Commence à s'intégrer.

Emmanuel — On a ça on a des écoles qui enseignent du bubble il y en a beaucoup en France d'ailleurs parce qu'on a une communauté en France assez forte on a un problème de certification qu'on fait tourner de notre côté parce que je pense que la certification est quelque chose qui doit être contrôlé par nous, pour certifier les gens pour être sûr que c'est des bons parce qu'il y avait, dès qu'il y a un écosystème il y a des charlatans partout, et donc c'est une catégorie qui a déjà émergé.

Bruno — Mais encore une fois toi ta population cible c'est pas les développeurs c'est pas les codeurs d'aujourd'hui. Ce n'est pas les codeurs d'aujourd'hui.

Emmanuel — Exactement. Même s'ils veulent venir, très bien. Mais ce n'est pas pour eux qu'on crée le produit. Parce que ça, c'était surtout important dans les débuts de la boîte, en fait. Aujourd'hui, c'est moins vrai. Mais aujourd'hui, je ne voulais même pas de coder, en fait. La difficulté avec les codeurs, c'est que comme ils peuvent de toute façon créer l'application, tu vas leur vendre un outil qui va leur permettre d'aller plus vite. Mais généralement, quand un outil permet d'aller plus vite, il permet de faire moins de choses. D'ailleurs, aujourd'hui, Bubble permet de faire moins de choses que le code, par définition. Chaque nouvelle abstraction, parce qu'on parle pas mal d'abstractions, permet d'aller plus vite, mais de faire moins de choses. On peut faire moins de choses en JavaScript et React qu'en assembleur. En assembleur, on peut faire concrètement n'importe quoi. Ce qui n'est pas du tout le cas de JavaScript.

Bruno — Mais chaque chose te demande plus de temps à faire.

Emmanuel — Mais ça demande plus de choses à faire. Mais du coup, le problème quand on travaille avec des codeurs, c'est que surtout quand on a une plateforme assez nouvelle qui, par définition, a pas mal de limitations. Aujourd'hui, on en a beaucoup moins, parce qu'en 12 ans, on a rajouté beaucoup de fonctionnalités. Les développeurs assez vite vont se plaindre déjà les développeurs sont des gens les codeurs pardon ce sont des gens assez chiants en général, on dira exigeants et voilà ils sont exigeants disons et ils cherchent toujours la petite bête et quand ils savent que de toute façon ils peuvent trouver une façon de le faire eux-mêmes à si vite on dit bon allez il y a trop d'imitations je m'en vais tandis que si on va vers les gens qui ne savent pas coder eux. Même au tout début de la boîte quand la boîte avait un ou deux ans et franchement ça faisait pas grand chose c'était pas joli c'était lent il y avait plein de bugs et tout ça c'était génial pour eux, ils regardaient ça avec des enfants en disant je ne pouvais rien faire maintenant je peux faire quelque chose, donc là où les développeurs voyaient les limitations, les non développeurs les codeurs voyaient les limitations les gens non techniques voyaient je ne pouvais rien faire maintenant je peux faire quelque chose et donc c'était beaucoup plus facile de développer le produit avec des gens comme ça parce qu'il y avait de l'enthousiasme et des gens qui étaient prêts à accepter nos limitations, ce que les développeurs au début n'étaient pas prêts à faire aujourd'hui c'est différent parce qu'on a quand même au bout de 12 ans enlevé énormément de limitations il n'y a plus beaucoup de limites en termes de comportement d'applications sur Babel donc maintenant les développeurs je suis très content de les avoir mais les gens pour lesquels j'ai créé le produit, et les gens et je répète ça à l'équipe tout le temps parce que, C'est assez difficile de garder ça, vu qu'on a quand même beaucoup d'ingénieurs en éterne, de leur dire qu'on ne crée pas la plateforme pour des ingénieurs ou des codeurs. On crée vraiment la plateforme pour des gens non techniques qui ont besoin d'un produit.

Bruno — Cette histoire me fait penser à l'arrivée de l'iPhone et de l'iPad, où il y a plein de gens, extrêmement geeks, on va dire, qui est tendance à dire que l'iPad, c'était nul parce qu'on ne pouvait pas installer les applications qu'on voulait, parce que c'était hyper fermé comme en environnement et compagnie, là où pour plein de gens c'était en fait c'est cool, c'est-à-dire que je risque pas de casser mon appareil, je peux pas installer n'importe quoi donc je peux pas installer un truc qui marche pas, qui va tout casser, qui va donc il y a...

Emmanuel — Je pense que de lancer des nouvelles technologies d'ailleurs pour, parler un peu de venture tout à l'heure généralement ce qui se disait beaucoup dans la Silicon Valley dans les années 2010 c'est qu'ils ne voulaient pas investir dans ce qu'on appelait les developer tools donc les outils pour codeurs parce que concrètement c'est une, Docker par exemple Très belle histoire Française aussi d'ailleurs Le fondateur est français Ça n'a pas été un succès commercial Exceptionnel C'est assez difficile De créer des outils Qui marchent très bien Pour les codeurs Parce que les codeurs Ce sont des gens Comme tu le dis De façon politiquement correcte Exigeants, Exactement Mais une fois que la technologie Se mature Ils ont beau être exigeants Ils ne sont pas cons Et à un moment Ils se rendent compte quand même Que finalement C'est le nouveau standard Et que ça marche très bien Et qu'il y a plein de choses à faire Et ils ne se plaignent plus Mais ça peut prendre 10 ans Et nous C'est ce qu'on a vu à peu près au bout de 10 ans ?

Bruno — Dans ton discours, j'entends que tu ne cibles pas les codeurs, que tu ne veux pas créer un produit pour eux, mais qu'au final, c'est un produit qui peut aussi servir cette population-là, en se concentrant du coup exclusivement sur les choses qui ont de la valeur et qui apportent quelque chose à l'application ou au service. Si on regarde un peu l'historique moi j'ai commencé à développer dans le web en 94, à l'époque on disait que les gens qui faisaient du JavaScript n'étaient pas des vrais devs parce que c'était du scripting c'était un petit truc aujourd'hui tu prends un dev React qui au final ne fait que du JavaScript, il y a quand même un niveau de complexité de problématiques qui sont hyper taffées c'est devenu un métier à part entière avec tout un tas de sous-spécialités et autres. Parce que il y a eu ce travers de développeurs qui sont arrivés là-dedans et qui ont commencé à ajouter des frameworks, des complexités, des capacités, des machins. Est-ce que toi t'essayes de prévenir ce risque-là, d'avoir des codeurs qui viennent te polluer ton produit en te disant, il faut qu'on fasse ça, il faut qu'on puisse faire ça, et qui en fait t'ajoutent un truc qui devient de plus en plus...

Emmanuel — Oui. c'est inévitable et ça demande une forte discipline en interne donc c'est là où il faut, répéter aux équipes pour qui on produit ce qu'on appelle la persona l'utilisateur type et je répète tout le temps à l'équipe pour des gens qui ne savent pas coder donc attention, n'introduisez pas de façon, sans faire attention des concepts qui vous vous parlent parce que vous êtes technique, parce que c'est pas ce qui marche avec nos utilisateurs et effectivement, on a une communauté qui est extrêmement active, et qui n'est pas avare en feedback et on a une idée, donc on a beaucoup d'idées qui viennent de nos utilisateurs et c'est une lutte de tous les jours de résister à ajouter certaines fonctionnalités qui on pense ne sont pas nécessaires après il y en a beaucoup qui le sont aussi donc c'est un, ce qu'on appelle en anglais un judgment call qu'on doit faire, c'est une question de jugement que tous les jours c'est des petites décisions produits qu'on doit prendre tout le temps pour éviter justement d'avoir un outil qui va trop vers la complexité, sachant qu'on est déjà assez complexe par rapport à la plupart des outils no-code. C'est-à-dire que je pense que de tous les outils sur les plateformes no-code, on est le seul qui, pour moi, vraiment est de la programmation, alors que les autres, c'est des outils visuels qui permettent de faire des choses, mais qui sont beaucoup plus cadrés, où on ne peut pas vraiment faire de la programmation. La grosse différence entre Bubble et les autres outils, c'est qu'on peut faire des bugs sur Bubble. C'est-à-dire que si on va faire ses workflows mal, et d'ailleurs, on a un debugger qui permet d'exécuter les workflows action par action, qui est un peu l'analogue du débogueur ligne par ligne en code traditionnel parce qu'on peut se planter ? Donc on est déjà assez complexe et notre approche c'est de ne pas avoir trop de limites parce qu'on veut que les gens restent sur la plateforme. Pour toute la vie de leurs produits mais il faut faire attention de ne pas en rajouter trop et pas d'exposer des choses que les codeurs demandent qu'ils le veulent parce qu'ils sont familiers avec ces concepts parce qu'ils viennent d'un ancien monde qui est le monde du code, mais qui ne je pense pas crée de valeur pour les utilisateurs en général.

Bruno — Du coup en fait ça y est l'union des métiers elle se fait là je pense que tu te souviens où tu avais vu passer que je crois que c'est Bill Gates qui disait que le métier d'un développeur c'est de créer des bugs parce qu'en fait tu crées une app qui n'existait pas avant qui du coup contient des bugs qui n'existaient pas avant en fait quand tu devs tu ne fais qu'ajouter des bugs bah bah c'est pareil donc bah félicitations tu permets effectivement à tes utilisateurs de créer des bugs supplémentaires à la totalité des bugs qui existent.

Emmanuel — Ouais et de former je parlais au début de l'éducation parce qu'il y a un aspect d'éducation encore.

Bruno — Une fois.

Emmanuel — Assez fort avec son fait de former les gens à utiliser le débugger et être un de nos challenges parce que c'est important que les gens se rendent compte que quand ils sont sur Bubble ils font de la programmation, c'est juste pas de la programmation qui est textuelle où on tape du code sur un clavier, ça se fait plus avec la souris mais c'est de la programmation.

Bruno — Ah oui donc il faut aussi avoir ce paradigme là effectivement le temps qu'on passe à débugger c'est comme tu disais tout à l'heure, on cherche des virgules mais au final c'est effectivement du débugage c'est une, vous sentez que vous perdez des gens sur ce truc là, sur le fait que cet acharnement à se dire ok il y a un problème il faut que je trouve, il faut que je comprenne.

Emmanuel — Ah bah oui, toujours. C'est-à-dire que dès qu'on crée quelque chose, que ce soit une application ou une feuille Excel ou n'importe quoi qui n'a pas le comportement escompté, tu vas perdre des gens, forcément. Et donc, il faut les former à réparer leurs propres erreurs.

Bruno — Vaste sujet T'as évoqué aussi un truc Que je trouve intéressant tout à l'heure C'est qu'effectivement ton produit il est créé par des devs Et donc faut créer un outil Qui est fait par des devs, Alors pas les remplacer on s'entend Mais d'une certaine façon Non mais les rendre.

Emmanuel — Non nécessaires pour beaucoup de tâches.

Bruno — Et comment tu fais Pour qu'ils aient ce mindset Et t'assurer qu'effectivement Ils rajoutent pas la complexité qu'ils ont naturellement En se disant c'est comme ça qu'il faut faire un site.

Emmanuel — Avec une équipe produit, une équipe design qui surveille ce qui se passe. Et c'est une question de recrutement in fine parce que de trouver des ingénieurs qui sont très alignés avec la mission et qui comprennent l'intérêt. J'ai envie de dire, c'est très difficile, je pense, très tôt. J'ai vu pas mal de tentatives de faire la même chose qu'on fait par des ingénieurs, en particulier à San Francisco d'ailleurs. Parce que quand je disais que la Silicon Valley n'était pas intéressée par ce qu'on fait, c'est pas vrai. Il y a quand même deux boîtes qui sont lancées en même temps que nous, un an après nous, où très vite, je les ai vus partir dans un truc pour développeurs, pour codeurs et ça n'a pas marché, donc je pense que très tôt il faut faire très attention et le fait que ni moi ni mon associé qui s'appelle Josh, on venait d'un background technique traditionnel c'est à dire qu'aucun de nous deux avait bossé dans des boîtes tech avant Josh était plus technique que moi à l'époque mais il avait fait de la philo il venait pas forcément d'un background très traditionnel, a été une force pour nous donc c'est très important au début après quand on est une boîte de 150 personnes et qu'on embauche d'ingénieurs, le produit est déjà établi, on a déjà une structure, donc il faut surveiller qu'on ne rajoute pas des fonctionnalités, qui ne sont pas nécessaires juste pour faire plaisir aux codeurs, mais il y a assez peu de risques que ça dérape trop, au sens où si tu n'as que deux personnes et que tu parles trop à des codeurs à l'époque et que tu commences à créer pour eux, là, ça dérape et ça ne marche pas.

Bruno — Les auditeurs et les auditrices le savent. Moi, je parle souvent d'outils no code à ce micro, même si je suis développeur, parce que je trouve que c'est des outils formidables et je recommande toujours à tout le monde d'essayer ces outils-là. J'ai vu effectivement pas mal d'outils apporter des concepts de staging, de versions de pré-prod, de logs et compagnie. Mais tu vois, au final, ça reste des pratiques. On voit quand même certaines pratiques du métier de dev.

Emmanuel — Oui, parce qu'il y a certaines pratiques du métier de dev qui ne sont pas stupides. Il faut avoir plusieurs environnements, il faut avoir plusieurs versions, il faut pouvoir avoir, un peu comme Git, ce qu'on a sur Bubble, des différentes branches, comme on dit en anglais, où on peut modifier des morceaux de l'application, les mergers, enfin tout ça. C'est d'ailleurs le truc plutôt marrant de ce qu'on fait c'est qu'on prend je trouve le mieux du métier de codeur et on le met dans les mains de non codeur je trouve ça super je suis très content de ce que je fais tous les jours.

Bruno — Après toujours la question étant est-ce que ce que toi tu choisis comme étant le mieux est effectivement le mieux pour tout le monde ça reste toujours.

Emmanuel — C'est un choix que tu prends c'est là où la création de produit il y a une intuition et un goût pour le produit qui est assez important parce qu'il n'y a pas de... C'est difficile. J'ai essayé de voir si on pouvait codifier certaines choses pour permettre aux équipes de prendre des décisions sur certains principes. Donc, on a certains principes du ex et de décision produit. Mais, in fine, c'est quand même beaucoup une question d'intuition et de goût... Alors après, ce n'est pas chaque petite décision à ça, c'est plutôt des grosses directions qu'il faut prendre. Donc, c'est peut-être 5-6 décisions par an. Ce n'est pas non plus quelque chose qu'on fait tous les jours. Mais où in fine, ça revient de l'intuition et de la vision produit.

Bruno — Le métier de développeur et de développeuse est un métier qui est en train de subir, peut-être pas un tsunami, mais en tout cas, il y a un certain tremblement qui est en train de s'opérer avec l'arrivée des LLM, des copilots et autres. Où il y a quand même une certaine fébrilité une certaine peur pour certains et certaines de voir leur métier se transformer, question extrêmement ouverte sur déjà c'est quoi toi ta vision parce que t'as des développeurs dans ta boîte donc comment est-ce que tu les amènes à travailler avec ces outils là, comment est-ce que vous vous inscrivez dans cette révolution de ce changement de métier, comment est-ce que les LLM sont, enfin tu vois, question très très vache, je sais pas par quelle.

Emmanuel — Il y a beaucoup de sujets on peut y aller par étapes si tu veux, sur l'avènement des technologies qui permettent d'écrire du code de façon plus facilement en interne pour nous, on les utilise un petit peu dans les faits et peut-être que j'ai pas trouvé les bons outils et peut-être que certains nos éditeurs ont trouvé les bons et si c'est le cas j'aimerais bien le savoir j'aimerais bien les connaître quand on est une codebase qui a eu 12 ans on a quand même beaucoup de choses, beaucoup de framework interne qu'on a développé en interne, comme la plupart des boîtes qu'on travaille pendant longtemps, ça marche pas super bien c'est à dire que les copilots chez GPT c'est très bien quand il s'agit de partir from scratch, en suivant les standards des derniers trucs parce que ces modèles ont été traînés c'est pas des modèles intelligents ils ont été traînés sur des milliards de lignes de code ils ont été traînés sur des choses qui sont du code open source sur les standards de l'open source, on essaye d'avoir des choses en interne qui sont aussi standards que possible mais dans les faits c'est pas comme ça que ça marche dans une boîte qui est établie le code chez Google ne ressemble pas à du code, d'un package open source qu'on trouvera sur GitHub et chez Bubble non plus donc on l'utilise c'est pas aussi encore. Ça n'a pas autant d'impact que ce que j'espérais au début après je sais qu'il y a des gens qui travaillent sur la question de traîner des modèles juste sur la base de code de l'entreprise mais ça marche pas encore très bien, après ça c'est la question plus profonde sur comment, l'intelligence artificielle générative peut impacter ce qu'on fait parce que si ça impacte la création d'applications par du code ça va forcément impacter ce qu'on fait. J'ai envie de dire que c'est un peu la même vision d'ailleurs c'est-à-dire que. Je parle toujours de Chagipity, mais c'est un peu un placeholder pour GnR en général, parce qu'il y a plein d'autres outils. Mais le fait de pouvoir taper en anglais ou en français à Chagipity et de dire crée-moi une application qui fait ça et ça génère le code, c'est très similaire à la vision de Bubble. L'idée, c'est de permettre aux gens de créer des applications de façon plus rapide. Donc, on est très alignés. C'est un peu de la compétition pour nous. C'est un peu une menace, mais c'est aussi une opportunité parce qu'on a l'opportunité d'intégrer le même médium, qui est donc un prompt-based, c'est-à-dire le fait de taper un prompt en langage naturel, dans notre outil pour créer des morceaux d'application ou une application complète, une application Bubble et donc c'est sur quoi on travaille on a lancé quelque chose la semaine dernière d'ailleurs en alpha donc c'est encore assez tôt où les gens peuvent décrire l'application qu'ils veulent créer, généralement les gens tapent en anglais mais je vais le dire en français créer une place de marché pour tel type d'objet. Et on génère l'application qui n'est pas du code donc on génère pas du code, on génère une application Bubble je pense que si on le fait bien on est en alpha donc il y a encore du travail pour bien le faire c'est la combinaison gagnante parce que le problème de l'intelligence artificielle qui génère du code c'est bien, mais il y aura toujours un moment où il va falloir tweaker des choses et réparer des choses et c'est pas parce que l'intelligence artificielle d'ailleurs n'est pas bonne c'est plus parce que l'être humain n'est pas bon pour écrire en langage naturel ce dont il a besoin quand il s'agit de créer une application, c'est à dire que le prompt ne marche pas très bien si ça marchait bien tout le monde enfin pas tout le monde mais la plupart des gens ont une très bonne expérience avec leurs développeurs dans les faits j'ai jamais rencontré quelqu'un qui adore ces développeurs et alors quand c'est de l'outsourcing et un cabinet de développement externe généralement ils veulent les tuer, et les crucifier parce que ça se passe toujours mal et ça se passe mal pas parce que les développeurs sont pas bons ça peut arriver il y a des charlatans partout mais souvent parce que le client n'est pas capable d'expliquer, de façon non ambiguë ce dont il a besoin. Parce qu'en fait, il y a tellement de degrés de liberté quand il s'agit d'écrire une application que c'est compliqué de l'écrire sur un paragraphe. Alors dans les grosses boîtes, d'ailleurs, ce n'est pas un paragraphe. Généralement, c'est un PDF de 200 pages avec des gens qui font ça depuis 20 ans. Et ça se passe quand même mal. C'est quand même compliqué. Donc, il y aura forcément des trucs à réparer et à changer. Et donc, du GNI qui va générer du code, c'est bien, mais il faut être un codeur. Et donc, on est revenu au problème initial, qui est que c'est 1% de la population mondiale qui s'est codé. Donc, ça permet de faire plus de choses, mais ce n'est pas suffisant. Alors que je pense que si on crée quelque chose qui génère une application dans notre langage à nous qui a l'avantage d'être beaucoup plus accessible parce que notre langage à nous étant visuel il est accessé par au moins 100 fois le nombre de gens qui savent coder et bien là on a le meilleur des deux mondes et donc c'est sur quoi on travaille, il y a du travail c'est un peu plus difficile que de générer du code parce que, la plupart des mois d'ailleurs des startups qui se lancent, qui créent des applications en générant du code, en fait ils ne font pas grand chose parce que c'est Claude et ChatGPT qui ont fait le travail, c'est OpenAI et Anthropic qui ont traîné des modèles sur les milliards de lignes de code qui sont sur GitHub, donc c'est plus facile d'avoir du code clean parce que les modèles ont été traînés nous c'est un peu plus compliqué parce qu'il y a moins d'applications bubble dans le monde et donc on doit faire du training de notre côté du prompt engineering pour bien le faire mais donc ça va prendre un peu plus de temps mais si on arrive à bien le faire ce sera beaucoup mieux que de générer du code.

Bruno — Alors je me permets juste une toute petite correction parce que tu as dit on a sorti un truc la semaine dernière je ne sais pas encore quand est-ce que ton épisode.

Emmanuel — Sera utilisé ça.

Bruno — Se fait tout seul mais donc c'est début décembre on peut.

Emmanuel — Dire qu'il en ait 5 non non 20 novembre 20.

Bruno — Novembre ok donc il y avait ça 2024 est-ce que tu penses que, que dans un avenir plus ou moins proche la majorité des applications et services seront créés par des outils similaires à Bubble.

Emmanuel — Oui bon après je suis biaisé évidemment mais oui j'en suis convaincu et j'en suis convaincu parce que in fine c'est la façon moins sexy quand même de décrire ce qu'on fait, quelle que soit la résistance qu'on a de l'écosystème, des CTO tu verras par exemple des directeurs IT dans des grosses boîtes qui vont regarder ce qu'on fait en disant oh là là qu'est-ce que c'est que ce truc là, mais parce que les gens ont leurs habitudes et tout ça mais in fine et encore une fois c'est moins sexy ce que fait Bubble c'est juste de réduire le coût de création d'applications par un facteur de 100 ou 50, on a du mal à savoir parce qu'il y a beaucoup de facteurs dedans mais quand on pose régulièrement la question à nos plus gros éditeurs combien vous pensez vous économiser en utilisant Bubble par rapport à avoir une équipe de dev traditionnelle pour créer vos applications, et le chiffre qu'on entend, c'est entre 50 et 100. Et donc, c'est juste moins cher. Et à un moment, les forces de marché, la quête de productivité et d'économie, parce qu'on est dans un monde où, enfin, le monde de l'entreprise cherche, enfin, j'espère pas que de l'entreprise, d'ailleurs, ça devrait être partout, cherche à faire des économies et être plus efficaces, fait que, naturellement, les gens, même s'ils résistent au début, vont aller vers les choses qui sont moins chères et faire du bubble c'est beaucoup beaucoup beaucoup moins cher que de taper du code et donc oui dans 50 ans j'ai aucun doute, et si c'est pas nous ce sera quelqu'un d'autre parce qu'il y a un besoin, il y a une opportunité pour faire des choses beaucoup moins chères et donc les gens naturellement les gens iront.

Bruno — Même s'il.

Emmanuel — Y a de la résistance à très court terme.

Bruno — Sur quasiment tous les épisodes où on parle de solutions no code ou low code je fais à peu près la même analogie avec le monde du cinéma, où il y a 50 ans si tu voulais montrer un film au monde entier il te fallait une équipe colossale il te fallait des équipements extrêmement chers il te fallait des producteurs, des diffuseurs, des annonceurs, des machins maintenant tu prends ton téléphone, t'appuies sur un bouton.

Emmanuel — Maintenant il y a des films qui se font sur l'iPhone et qui sont de super qualité et c'est ça.

Bruno — C'est que ça n'empêche pas et on continue à faire du cinéma à l'ancienne pour autant, parfois bien parfois pas bien, il y a des trucs effectivement brillants qui sont faits avec des téléphones et des trucs nuls, mais effectivement on produit plus de contenu aujourd'hui avec nos téléphones qu'on n'en a jamais produit avec des caméras traditionnelles.

Emmanuel — Exactement, et il y aura toujours des gens de même qu'aujourd'hui il y a des gens qui travaillent encore en argentique, pour faire des photos il y aura toujours des gens qui resteront sur le code, pour des usages particuliers et c'est très bien, donc notre but n'est pas de remplacer le code souvent les gens, on dit ça dans les médias les gens disent ça dans les médias mais c'est une façon de simplifier les choses parce que c'est un peu catchy, mais c'est pas ça on essaie pas de remplacer le code, on essaie de rendre le code non nécessaire pour 95% des besoins ce qui est très différent, mais il y aura toujours 5% des besoins où les gens continuent à faire du code de même que oui, pour faire des films, des gens travaillent encore avec des pellicules ou de l'argentique parfois.

Bruno — Et puis en plus on pourrait aussi réduire le scope aujourd'hui avec Bubble tu peux créer une application sage, tu peux créer un site web mais si je veux faire un appareil IoT par exemple, a priori Bubble ne sera pas la...

Emmanuel — Pas encore mais le mobile, parce qu'au bout de 12 ans on n'avait pas encore de solution native mobile mais le mobile sort l'année prochaine et c'est déjà en bêta en ce moment et utilisé par des utilisateurs donc maintenant on peut faire des applications natives qui sont du vrai natif, pas de l'hybride, sur React Native pour iOS et Android donc l'IoT sera la prochaine plateforme. La difficulté de l'IoT, c'est que c'est... Généralement, il n'y a pas vraiment d'interface graphique... Et donc, Bubble est sans doute un peu moins adapté. Cela dit, on a un système de création de back-end, ce qu'on appelle les back-end workflows, qui sont en gros des flowlogies qui marchent par API, où on pourrait, j'imagine, faire plein de choses.

Bruno — Ah, donc il y a quand même une ambition de partir sur tous les...

Emmanuel — Mon ambition à 50 ans, c'est d'être le stand-up dans 50 ans. J'espère que les gens veulent créer du logiciel quel qu'il soit. Le premier réflexe, c'est d'aller sur Bubble. S'il s'avère qu'on n'est pas dans les 95% des cas où ça marche, c'est que c'est 5% de même qu'aujourd'hui. Il y a encore des gens qui font des 0 et des 1 pour certains trucs ils retourneront vers des trucs de plus bas niveau mais moi mon ambition est d'être un standard, donc si on a un standard c'est à dire qu'on est partout sur toutes les plateformes.

Bruno — Et du coup c'est à dire qu'on pourrait demain imaginer créer un LLM sur Bubble.

Emmanuel — C'est typiquement un truc qui restera dans les 5% où une interface graphique sera pas, quelle qu'il soit d'ailleurs je pense ne sera pas la bonne approche je me trompe peut-être, je suis pas un expert en intelligence artificielle mais de ce que je comprends comment ça marche j'ai du mal à voir comment on pourrait faire ça avec un.

Bruno — Logiciel visuel donc on disait aussi tout à l'heure que t'ajoutes une nouvelle couche d'attraction je me souviens en préparation, tu m'avais dit on s'en fout un peu de ce qui se passe dans les couches en dessous il y a effectivement ce parallèle comme quoi t'es plus proche de javascript que javascript ne l'est d'assembleur j'ai reçu il y a quelques temps sur ce podcast j'en parle de plus en plus j'ai l'impression, le tech lead de l'équipe Android de Deezer, qui a tenu un propos qui est devenu un extrait TikTok qui a été le extrait TikTok le plus, vu sur ma chaîne où il disait, regretter de voir de plus en plus de développeurs et développeuses d'entretien qui ne connaissent pas la différence entre TCP et UDP donc il y a eu une guerre dans les commentaires sur est-ce que c'est nécessaire de connaître ce genre de choses quand t'es développeur, et du coup je te pose la question est-ce que vraiment on peut s'en foutre des autres couches en sachant que, je te pose ça sur ce micro là où moi j'ai créé ce podcast parce que justement ma conviction personnelle c'est que pour être développeur faut connaître plein de choses faut s'ouvrir les chakras on en a à découvrir d'autres technos, d'autres sujets d'autres domaines et que tout ça ça t'enrichit et ça te rend meilleur.

Emmanuel — Je pense que c'est pas nécessaire mais c'est mieux C'est mieux d'avoir de la culture générale, de la culture générale technique, de la culture générale en général, mais je ne pense pas que ce soit nécessaire. C'est un peu le vieux monde, sans être méchant avec la personne qui a dit ça, mais c'est un peu le vieux monde. Peut-être que c'est vrai pour ce concept-là aujourd'hui, mais il y a plein d'autres concepts où la plupart des développeurs ne savent pas comment ça marche. Combien de développeurs aujourd'hui savent programmer en même encée ou en assembleur ? Enfin, il n'y en a pas, quoi. Et ça se passe très bien. Donc, pourquoi ce serait vrai pour... Qu'est-ce que c'était, la TCP ?

Bruno — TCP versus UDP.

Emmanuel — Voilà. Pourquoi ce serait vrai pour ça et pas pour des choses, le BIOS ou des trucs de très bas niveau ? C'est un peu arbitraire. Et à chaque fois qu'on va rajouter une couche sur le stack, les gens d'ailleurs, peut-être ne savent pas en anglais mais stack c'est une pile donc c'est vraiment ce dont on parle, c'est-à-dire qu'on rajoute des couches sur la pile quoi, dès qu'on rajoute une couche sur la pile ça fait qu'il y a moins besoin de savoir des choses donc tes CPU, DP peut-être qu'aujourd'hui dans le monde, peut-être ça a encore de la valeur je suis pas sûr, mais dans deux ans ça n'aura plus de valeur parce que les outils, l'abstraction ce sera augmenté, cette idée de rajouter des couches d'abstraction d'ailleurs c'est pas nous qui l'avons augmenté, c'est l'histoire de la technologie, l'évolution des outils technologiques en particulier en programmation ça n'est qu'une création d'une couche après l'autre qui font que les outils permettent d'aller plus vite d'être plus efficace, encore une fois parce que c'est moins cher c'est là où je dis c'est moins sexy c'est moins sexy pour bubble mais moins sexy pour tout le monde c'est qu'in fine le but de ces trucs c'est pas de créer des plateformes qui sont plus plaisantes et utilisées pour les développeurs on s'en fout, c'est de créer des trucs qui sont moins chers parce que les gens ont besoin de créer des choses qui coûtent moins cher parce que c'est ça qui permet les forces de marché font que c'est les gens qui font des choses, qui paient moins d'argent pour faire des choses qui grossissent, c'est le darwinisme du business.

Bruno — Et puis après c'est peut-être aussi une question de distance entre les couches, c'est-à-dire qu'effectivement aujourd'hui quand t'es développeur, faire de l'assembleur ça a peu de sens, si demain on passe sur un environnement similaire à Bubble effectivement connaître les couches réseau en fait c'est une question de profondeur c'est pas la peine de creuser dans 8 couches si tu connais les 2 couches qui sont en dessous de toi déjà c'est très bien.

Emmanuel — Mais après c'est de la culture générale C'est jamais mal d'avoir de la culture générale Mais c'est pas nécessaire.

Bruno — Très bien Merci beaucoup Emmanuel pour cette conversation J'aurais deux dernières questions pour toi Qui sont les questions rituelles du podcast IFTTD La première c'est est-ce qu'il y a un contenu Que tu voudrais partager avec l'ensemble des auditeuristes.

Emmanuel — Oui un livre que j'ai lu récemment Je sais pas si c'est un livre business, Mais qui en l'occurrence dans le business M'a beaucoup aidé Ça n'a rien à voir avec la programmation Mais que je dirais en anglais Comment gagner des amis et influencer les gens en français, qui a un livre qui date des années 30, donc je lis assez peu de bouquins business personnellement, je trouve qu'il y a quand même beaucoup de bullshit dans ces bouquins, mais ça c'est un livre déjà qu'en cent ans plus tard on en parle encore, c'est qu'il a une certaine valeur et qui, Qui m'a beaucoup aidé à essayer d'être un meilleur leader de deux gens. Parce que maintenant, c'est quand même mon boulot. Ça fait plusieurs années maintenant que je n'ai pas écrit de code. Et aussi dans la vie personnelle, d'ailleurs. Et en particulier dans un concept américain. Bon, moi, je suis biculturel au sens où je vis aux Etats-Unis depuis 14 ans maintenant. Mais je reste français avec les travers français qui ne sont pas forcément toujours compatibles avec nos amis d'outre-Atlantique.

Bruno — Je vois. Bah top. On mettra bien évidemment un lien en description. Et dernière question. Est-ce que tu es plutôt espace ou tabulation ?

Emmanuel — Tabulation.

Bruno — Très bien. Merci beaucoup Emmanuel.

Emmanuel — Merci.

Bruno — Et merci à tous d'avoir assisté à cet épisode. J'espère que vous avez donné envie de découvrir Bubble parce que c'est vraiment un outil sympa. Alors moi je ne l'ai pas utilisé, vous le savez j'ai autométisé toute ma production de podcast je n'ai pas eu l'occasion de l'utiliser encore mais je commence à découvrir l'outil, notamment pour créer un outil SaaS autour de la production de podcast donc j'espère que j'arriverai dans les délais que je me suis donné d'y arriver mais en tout cas c'est un super truc et je trouve qu'en termes de boilerplate tu gagnes un temps fou parce qu'il y a déjà. Tout un tas de trucs qui sont au final assez casse-pieds à faire, même pour nous en tant que dev qui sont déjà là donc allez jeter un oeil, merci aussi de partager ce podcast autour de vous de mettre un commentaire 5 étoiles aussi, ça fait toujours plaisir je vous souhaite une très bonne fin de semaine je vous dis à la semaine prochaine et d'ici là, codez bien.