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.
