Bonjour à tous et bienvenue sur ce nouvel épisode de Double Slash. Je suis Patrick et comme
d'hab on est avec Alex. Salut Alex. Salut à tous. Donc petit message, je voudrais passer
juste un petit bonjour aux gens qui nous écoutent d'Afrique. Parce qu'on voit dans les stats
qu'on a des gens qui écoutent en Afrique, notamment au Sénégal. Donc merci de nous écouter et
puis n'hésitez pas à nous envoyer un petit message ou laisser un petit commentaire. Ça nous fait
toujours plaisir. Et donc aujourd'hui le sujet du jour c'est Web Assemblée et on a un invité qui
est Yvon Enderlin. Salut Yvon. Salut à tous. Voilà donc on va te laisser te présenter. Qu'est-ce
que tu fais ? Ok. Alors tout commence en 1988. Ça va être long. Ça va être très très long. Ma
première d'anglais, non ça s'est fait. Non alors à la base moi je suis chercheur, docteur
plutôt en informatique. Et puis après je n'avais marre de la recherche donc je me suis cassé. J'ai
bossé pour Mozilla entre autres, automatique. C'est ceux qui font WordPress.com, WooCommerce
et tout ça. Et puis après j'ai rejoint Wazmer. Donc j'ai un background assez large. J'ai commencé
à programmer très jeune par du C. J'ai fait beaucoup de web. Là je suis de retour sur du
système avec du reste et tout. Donc voilà grosso modo. Et aujourd'hui je bosse pour Wazmer. Je suis
co-finateur et on édite un runtime Web Assemblée qui s'exécute pas dans le navigateur mais côté
Serba. D'accord. Ok. Et du coup c'est ta boîte Wazmer ? En fait j'ai rejoint au tout début et je
suis passé late co-founder tout récemment. Parce que en fait voilà. Comme je t'ai dit depuis le
début de la boîte, ça se fait dans les startups que ceux qui sont présents depuis toute l'histoire
de la boîte deviennent co-finateurs après. Donc j'ai rejoint la boîte avec trois semaines après,
à peine. C'était véritablement le début. Donc du coup on entend. Pourquoi on a voulu t'inviter
tout simplement ? Parce que depuis, on est plutôt développeur front javascript, etc. Enfin tout ce
système là. Et on entend parler de plus en plus de web assemblée, Wazmer, etc. Donc on se posait
question. Est-ce que aujourd'hui ça vaut, c'est intéressant ? Donc on va commencer par la première
question. WebAssembly c'est quoi en fait ? Alors quand vous avez un langage comme du C, du REST,
des langages qui se compilent, en général vous allez compiler vers une cible. Ce qu'on appelle
une cible de compilation, une target. Et en général c'est un code exécutable natif pour votre
WebAssembly. C'est une cible alternative. C'est aussi une sorte de bytecode si vous voulez,
mais qui ne cible pas un OS en particulier. C'est suffisamment bas niveau pour avoir un
jeu d'instruction qui est très réduit, mais ça cible pas une architecture ou une plateforme
en particulier. Donc l'avantage c'est qu'on peut facilement l'interpréter, donc l'exécuter à la
volée ou le recompiler vers du code natif exécutable très facilement, très rapidement et du
coup ça rend le format hyper portable et hyper versatile. J'ai oublié la traduction en français
de versatile, mais polyvalent. Ça rend le truc hyper polyvalent parce qu'on peut du coup l'exécuter
dans le navigateur et tout ça. Et ça vient pas de nulle part. WebAssembly c'est une technologie
qui est le résultat de plusieurs années et plusieurs projets itératifs. Donc à la base on
avait JavaScript dans le navigateur, je ne sais pas si vous connaissez. JavaScript c'est sympa,
mais c'est pas assez performant. Malgré tous les efforts extravagants et incroyables,
des ingénieurs qui bossent sur les runtime.js chez Firefox, chez Mozilla ou chez Google et autres,
opérants. Donc du coup ils ont commencé, Mozilla avait eu l'idée de faire ASM.js,
c'était une sorte d'assembler.js. Donc l'idée c'est d'ajouter quelques types,
très très peu d'opérateurs, très très peu de construction de langage. Tout ce qu'est objet,
comme l'objet MAT ou WebGL ou je ne sais pas quoi, c'est des choses qu'on importe, donc ce n'est
pas un natif. Et puis le but c'est d'accélérer à fond l'exécution JavaScript. Et ça a bien
marché. Dans notre côté, il y a Google qui avait sorti Pineapple, donc c'était une sorte d'alternative
aussi à ça. Et en fait c'est la fusion des deux. Il y a quand même beaucoup de beaux mondes qui ont
donné naissance à WebAssembly. Mais essentiellement on va dire Mozilla et Google, il y avait aussi
un petit peu Intel dans le lot, je crois, des gens comme ça. ASM c'était un langage à part
entière créé pour tourner plus rapidement que JavaScript. En fait c'était vraiment un sous-ensemble
de JavaScript. Après il y avait juste une sorte de mini-instruction comme on a U-Strict en JavaScript,
il y avait un équivalent pour ASM.js. Et l'idée c'était que du coup le runtime, il avait des règles,
enfin il savait qu'il pouvait avoir des règles un peu plus strictes sur les types et genre de choses,
et du coup il pouvait avoir des optimisations plus agressives. Et c'est avec ASM.js qu'on a
commencé à avoir les premières démots de jeux vidéo. Si je ne sais plus quel moteur c'était,
c'était pas Unity, c'était l'autre. On commençait à avoir des vrais jeux vidéo avec une vraie 3D,
enfin un truc hyper intensif en calcul qui est dans le navigateur. WebAssembly c'est né de là.
Donc on avait Mozilla, Google, Microsoft, Apple, W3C avec Intel, qui sont tous mis ensemble. On a dit
on fait un truc. Mais avec la volonté que ça ne soit pas que côté navigateur. Il n'y avait pas
encore l'ambition je pense d'aller sur le côté serveur et tout. Mais en tout cas ils ne sont pas
fermés de la porte. Et ils ont bien fait. Et aujourd'hui c'est totalement ouvert,
comment est structuré et organisé le langage ? Est-ce que c'est la communauté ? C'est des
comités ? C'est des relectures ? Comment ça se structure ? Comment le langage évolue aujourd'hui ?
Alors je peux vous vendre le vrai discours ou alors je peux vous dire la vérité. La vérité c'est
que c'est un peu le bazar. Mais ça marche quand même vraiment bien. Donc tout se passe sur
GitHub en fait. Et on avait une sorte de MVP qui a été fait. C'est ce que tous les navigateurs ont
implémenté assez rapidement. Et après pour chaque nouvelle feature on va dire on a des proposers.
C'est un peu comme dire commandation pour W3C. Et là on a beaucoup d'acteurs qui
participent. Ça dépend des proposers parce que toutes ne sont pas intéressantes pour tout le
monde. Et donc c'est un peu par centre d'intérêt que les gens se regroupent et disent ah,
ce serait bien de faire ça etc. Et après on a des gens quand même qui chapeautent un peu tout ça.
Qui ne sont pas payés par le web à s'en bien. On ne soit pas une fondation. Il n'y a pas de
volontaires qui pendant quelques temps une année ou deux vont diriger un peu des travaux. Il y a un
niveau un peu meta quoi. C'est genre ok, tels proposers là tels ou peut-être qu'on peut les faire
converger ou ce genre de choses. Mais libre à vous d'ouvrir une issue sur GitHub pour discuter
ou dire ah, j'ai ce besoin là. Mais il y a beaucoup d'évolution où c'est très lent en fait.
Ça dépend des proposers. C'est lent par nature parce qu'on a quelque chose d'extrêmement
polyvalent et on n'a pas envie de l'enfermer dans un cas d'usage particulier. Ça reste quand même
assez technique parce qu'il ne faut pas apporter trop de fonctionnalités trop au niveau. Il faut
que ça reste, c'est comme une cible de compilation donc il faut que les compilateurs puissent générer
ce qu'on a envie d'avoir. Donc il faut aussi travailler avec tous les gens qui édite les
compilateurs, que ce soit pour l'LVM ou Rust C pour l'engage Rust. Il y a plein de langages
qui compilent maintenant vers WebAssembly. Du coup là on peut les citer, il y a assez, c'est plus plus
Rust, Swift, Assemblyscript qui est une sorte de subset, un sous-ensemble de TypeScript,
TypeScript qui est une sorte de JavaScript type. Donc voilà, on a plein de choses qui bougent
en ce sens là. Ok, super. Et donc en tant que développeur web, comment ça marche dans le
navigateur ? Comment je peux utiliser WebAssembly ? Comment l'utiliser ? C'est ça en fait ? L'interfacer ?
Oui, il a double 3C, des acteurs de double 3C ont écrit une spécification, une recommandation.
Donc il y a une API standard pour utiliser WebAssembly joué dans l'invigrateur. Et finalement
cette API, elle est très simple, il n'y a pas besoin qu'elle soit plus complique que ça,
parce que WebAssembly à l'usage, c'est très facile. C'est plutôt dans le détail comment
fonctionne le runtime et tout ça, où tous les nouveaux proposoles vont un peu changer les choses,
mais l'API publique qu'on peut offrir à l'utilisateur, elle bouge quasiment très peu. Donc voilà,
du coup, double 3C a cette spécification, cette recommandation, et puis elle est implémentée
par quasiment tous les navigateurs modèles. En tant que dev, front, moi si je vais utiliser WebAssembly,
c'est simple en fait. Après, les évolutions, tout ça, ça ne change pas beaucoup mon usage.
C'est ça. Après, par exemple, récemment, il y a eu beaucoup plus d'instructions SIMDI
quand elle était rajoutée. Donc ça, c'est hyper cool. Ça veut dire que dans le navigateur,
dès qu'il est prêt d'en compte et excite ton fichier WebAssembly, les a aussi, à ce moment-là,
ça va s'exécuter plus vite. Mais quelque part, ça reste du détail. Pour l'utilisation,
ce n'est pas un truc qu'on ne va pas avoir, on va pas devoir mettre à jour ces APIs tous les quatre matins.
Donc si on comprend la complexité, elle est quand même sur la compréhension, sur la création,
en fait, de ce que tu vas délivrer. Mais après, sur l'utilisation, c'est assez fluide et facile.
Exactement. Et puis sur la génération des modules, ça ne s'amplice pas des fichiers,
c'est des modules. La génération de ces modules, elle est faite par le compilateur,
par la toolchain, en fait, la suite du compilateur, du langage que vous utilisez.
Donc ce n'est même pas une complexité qui revient à l'utilisateur en soi.
Ok. Et ça, tu peux l'exécuter dans ton navigateur côté front, mais tu dis aussi que vous pouvez le faire
côté server, en un runtime server aussi possible ?
Exactement. Donc côté navigateurs, on ne peut rien faire. C'est un navigateur qui offre le runtime.
Donc dans Firefox, en fait, c'est le runtime de JavaScript qui comprend aussi WebAssembly.
Pareil dans Chrome, c'est G8 qui va gérer ça. On doit faire Fox et Spider-mankey.
Mais après, en dehors des navigateurs, il y a pas mal aussi de runtime de WebAssembly,
Rozmer sur lequel je travaille. Mais il y a aussi d'autres, Rozome 3 qui est un interprèteur et
la pleine. Et en termes de use case, on va dire de cas pratiques,
clairement, quels sont les intérêts de l'utiliser plutôt dans le navigateur ou plutôt sur un
runtime server pour qu'elle s'auraient un cas pratique ? Dans les cas qui sont intéressants,
le côté versatil, on peut exécuter le même code côté client et côté serveur.
Il suffit de prendre le même module. On peut l'exécuter dans le navigateur avec le runtime
qui est fourni par le navigateur à travers la pays du W3C. Et puis si vous avez, je ne sais pas,
dans du Python ou Node.js, côté serveur, Node.js, c'est basé sur V8. Donc vous pouvez exécuter
ce même module au bassemble. Si vous avez du Python, on a une intégration de notre runtime dans Python,
dans PHP, dans Java, dans Rust, dans C, dans Wigly, dans plein de choses. Donc après, il y a
vraiment ce côté universel de WebAssembly, on peut l'exécuter absolument partout.
En fait, tu codes une fois ton système et après tu le mets ou tu veux. Ça marche partout.
Exactement. Et le gros avantage, c'est pour des bibliothèques, je ne sais pas,
imaginez une bibliothèque de reconnaissance faciale, par exemple. Je ne sais pas,
vous voulez pouvoir identifier vos utilisateurs sur votre site et vous avez donc de scanner des,
je ne sais pas, des permis de conduire ou des trucs comme ça. Mais pour faire de la reconnaissance
faciale, vous pouvez très bien avoir une bibliothèque en C++ qui est hyper utilisée par tout le monde
depuis dix ans. Vous la compilez vers WebAssembly, pouf, vous pouvez utiliser dans le navigateur.
Et si jamais vous avez besoin de refaire des traitements derrière côté serveur,
vous pouvez la réutiliser aussi côté serveur. Et même si vous êtes en JS côté front et
en Python par exemple côté backend, vous utilisez un programme qui a été écrit en C++
par exemple. Et ça c'est assez beau. Et donc en fait, on pourrait dire que ça serait la glu entre
tout ce qui est possible. On vient tout compiler vers ça et au final on utilise un peu tous les
langages et toutes les techno qu'on voudrait. On pourrait tous les faire converger vers un seul et
même truc qui serait en fait le WebAssembly qu'on pourrait utiliser partout.
Oui, c'est un peu ce côté universel. C'est un peu la première de WebAssembly.
Il y a aussi un autre aspect qui est extrêmement important, c'est la sécurité WebAssembly par
design, par conception et fortement sandboxé. En français, c'est compliqué et très bien,
c'est bac à sabler. En fait, WebAssembly n'utilise pas la mémoire du système.
Il a chaque module à sa propre mémoire, biais tout au plus en mémoire. Et c'est normalement
impossible, sauf si il y a une erreur dans le runtime, mais normalement c'est impossible de sortir
de cette mémoire. Donc ça veut dire que vous pouvez très bien avoir des calculs assez critiques
qui sont faits dans WebAssembly côté front et j'avais écrit pour ne jamais y avoir accès.
Et côté backend, vous pouvez très bien intégrer des modules aussi qui font des calculs critiques
ou un peu secrets dans votre programme même. Ça peut être une extension à votre programme et
ça ne pourra jamais attaquer la mémoire. Donc imaginez un jeu vidéo, je ne sais pas lequel. Et puis,
vous voulez avoir des extensions qui s'executent rapidement et vous pouvez très bien utiliser
un runtime WebAssembly et accepter tout type d'extensions des gens qui sont compilés vers
WebAssembly. Et vous pouvez intégrer directement dans votre logiciel sans avoir peur de « Ah,
quelque chose ». En fait, c'est security by design, mais nativement.
Exactement. Excellent.
Là, depuis que j'écoute, j'ai l'impression que c'est le futur WebAssembly. Ça a l'air de être
top, c'est universel. Mais est-ce qu'il y a des défauts ? Parce que là, ça a l'air parfait.
C'est quoi les drawbacks ?
Je pense que le plus compliqué de base pour les utilisateurs, mais il y a des outils qui
comblent ça, c'est que pour l'instant WebAssembly ne comprend que quatre types de données. Donc,
c'est des entiers sur 32, 64 bits et des flottants sur 32, 64 bits. Donc, tout est un
entier au final. C'est juste qu'on a toujours essayé de construire des types de plus en plus
complexes sur ces entiers. Donc après, on a eu des tableaux, des chaînes de caractère après
des structures, des types éinus, des gens de choses, des objets un peu plus complexes. Mais
pour l'instant, comme on le sait bien, on n'en est pas encore là. Donc, on a juste quatre types et
c'est que des entiers et des flottants. Donc, ça veut dire que quand vous dites, par exemple,
appeler une fonction de ce module WebAssembly et que vous les passez une chaîne de caractère à
cette fonction, vous êtes obligé en fait de manuellement allouer la chaîne de caractère
dans la mémoire de WebAssembly. Et après, vous avez un pointeur en échange et vous êtes cette
fonction, vous lui passez ce pointeur. Donc, ça peut des fois rebuter un peu quelques personnes,
mais il y a des attenuatives. Par exemple, le langage qui supporte le mieux WebAssembly aujourd'hui,
c'est Rust. Dans Rust, il y a une bibliothèque qui s'appelle Wasm by N'Jain, qui va automatiquement
en fait générer toute la partie glue en JS pour justement passer n'importe quel type d'objet
ou depuis votre module WebAssembly utiliser les API JavaScript du navigateur, d'hommes et compagnie.
Donc, il y a plein de choses qui sont automatisées. Mais ça, c'est plutôt par langage. Assemblix
script fait un peu la même chose. Il propose aussi des API similaires, mais là, c'est un effort
individuel avec des bibliothèques et genre de choses. Ok, Rust est super avancé. C'est génial de
voir. En fait, toi, tu ne t'en occupes plus avec Rust. Tu s'occupes tout seul d'aller
avec la mémoire, tout ça, transformer. C'est ça. C'est vraiment tout automatisé. Donc, ça,
c'est vraiment, vraiment chouette. D'ailleurs, aujourd'hui, il y a des frameworks web qui sont
écrit en Rust qui compilent en fait vers WebAssembly. Et vous avez juste une fonction à
appeler et c'est fini. Tout d'outre appuie se lance comme ça et c'est entièrement WebAssembly.
Et ça a interagé que navigateur entièrement. Il n'y a rien à faire.
Ah ouais, carrément. En fait, j'ai envie de dire qu'il faut s'y mettre aujourd'hui en fait
à WebAssembly, non ? En tant que débatante. Moi, je me suis mis il y a deux ans parce que j'avais
commencé à hacker un peu. Enfin, à l'époque, je faisais encore un peu de PHP et puis j'avais
envie de mettre WebAssembly dans PHP pour faire du traitement d'image, en fait,
pas avoir besoin d'essai, des extensions, des machins comme ça. Et puis, c'est comme ça.
Alors oui, ça marchait. En fait, c'était aussi pour WordPress.com. Enfin, WordPress,
ça avait une... Ouais, était en train de construire un nouvel éditeur à l'époque qui s'appelait
Guttembert. Ouais, qui est une tuerie. Enfin, je trouve le fonctionnement de Guttembert a juste
magnifique. Et du coup, il y avait un problème, c'était pour pouvoir parser en fait des énormes
documents de plusieurs Mégas. C'était avec un parser qui était écrit avec BigJS. C'était
vraiment trop lent. Ils avaient des gros problèmes avec ça. Et donc, mon délire à moi, c'est
dire, OK, on est créé un parser en REST, on le compile vers WebAssembly, on l'utilise
côté front et côté backend aussi, donc côté front en Gs, côté backend en PHP. Et ça marchait
hyper bien. On avait des performances de Dingo. On passait de plusieurs secondes à quelques
10 secondes pour parser des documents de plusieurs Mégas. Donc, c'était vraiment très efficace.
C'est comme ça que j'ai commencé à mettre le pied dedans. Mais c'était pas pidouille.
Et aujourd'hui, c'est utilisé dans Guttembert ?
Alors, ça n'a pas été retenu parce que voilà. Mais c'était vraiment un projet hyper chouette.
Il ne garde pas l'idée de ne pas l'intégrer un jour. C'est vraiment...
C'est pas partie de la priorité des deadlines et gens de choses.
Après, à t'écouter, on voit qu'il y a quand même beaucoup de... Il y a tout un
écosystème qui s'est développé autour de WebAssembly. Par définition, en fait,
il interagit avec plein de langages. Donc, ce qui peut amener une grande complexité.
Aujourd'hui, en tant que dev, j'ai envie de m'intéresser à WebAssembly. J'ai envie de commencer
à trifouiller par où je commence. Qu'est-ce que tu as des infos ? On va dire des best practices
pour commencer et se mettre dedans. Par quoi je commence ?
Tout dépend du langage avec lequel vous êtes le plus à l'aise. Si par exemple,
vous aimez Rust, fait du Rust, c'est la vie. Si vous aimez Rust, il y a le groupe de travail
qui s'appelle Rust-Ozum. Ils ont un livre complet qui est en ligne gratuit et accessible.
Qui explique étape par étape comment utiliser WebAssembly dans Rust. Si vous utilisez Assemblix
Script, ils ont aussi une suite de tutoriels et chante-chose. Swift le fait aussi. En C,
c'est plus compliqué parce qu'il n'y a pas de documentation un peu centralisée. Mais si vous
faites du C, non, la biseille ne vous fait pas peur. C'est un peu tout ça.
En fait, on va partir d'abord de notre langage de prédilection et après, on va s'arranger pour
trouver le support ou l'export sur WebAssembly au sein de notre langage initial.
Si je fais du JS, c'est quoi le mieux ? Le problème, c'est que JavaScript ne compile pas vers
Assemblix Script. Assemblix Script, c'est vraiment un sous-ensemble de TypeScript.
Ça ressemble quand même pas mal à JavaScript dans l'idée. Moi, je recommanderais Assemblix Script
aujourd'hui. Leur objectif, c'est d'avoir TypeScript qui compile vers Wasm.
Pour Dufond, je pense que c'est la meilleure ressource aujourd'hui avec Rust. Je parlais de
ce framework. Ça s'appelle U, c'est Y-E-W. Je trouve qu'ils font aussi un excellent travail.
U, c'est quoi ? C'est en Rust. C'est un framework en Rust qui compile vers Wasm pour faire du Web.
Il y a une grosse commune aussi derrière. Là, je regarde le depot de Git, il y a 16000 stars.
Ça bouge. Au final, on peut dire que Rust, comme t'as dit, c'est le plus avancé pour WebAssembly.
Mais après, c'est plutôt par rapport auquel langage t'es à l'aise.
Après, tout le langage dynamique, comme Python, PHP, etc., ne compile pas vers Wasm.
Par contre, on peut compiler les run-times. On peut compiler le C Python, donc le run-time
de Python. On peut le compiler vers Wasm, le mettre dans le navigateur et exécuter un programme Python.
Je ne dis pas que c'est une bonne idée, mais c'est possible.
Mais il n'y a pas un truc comme ça sur Parcel, qui est un bundler qui accepte par défaut des fichiers
beaucoup plus ouverts. Il n'y a pas une intégration avec WebAssembly, où on peut directement mettre
son fichier. Il y a pas mal de bundlers qui permettent de créer des packages avec des fichiers
JS et WebAssembly. Il y a pas mal de choses qui existent. Il y a un truc qui automatique
absolument tout, qui est aussi fait par ce groupe, la Rust Wasm dont je parlais. Ce projet s'appelle
Wasm Pack. Ça fait absolument tout automatique. La fin, vous pouvez même publier sur
NPM, alors que la base de un programme en Rust. Tout est compilé, les libres JS sont génératiquement.
Vous n'avez juste plus rien à faire. Si, il faut quand même connaître. Un moment donné, il faut quand même
faire ce qu'on avait prévu. C'est un truc qui vient de nous assister.
Oui, parce que ce qui est compliqué là-dedans, on a envie d'être productif. On écrit le programme.
Après, toute la gluie autour pour brancher à JS ou NPM ou un ODE, on n'a pas envie de se
prendre état avec ça. C'est quelque chose qu'on peut automatiser.
Carrément. Carrément.
Ça donne vraiment envie de s'y mettre. Déjà, la dernière fois, on a fait l'épisode avec
Militiairch. Moi, perso, ça m'avait super motivé pour Rust et WebAssembly.
Du coup, là, tu me donnes encore plus envie. Ça donne vraiment envie de s'y mettre.
Ça semble vraiment quelque chose d'avenir. Si vous n'avez pas envie d'apprendre Rust,
je vous conseille énormément à WebAssembly script. Après, il y a aussi Swift qui compile vers WebAssembly.
Il y a plein, plein, plein de langages. Il faut vous dimettre. Vous n'avez pas d'excuse.
C'est clair.
Non excuse.
Et tu as rejoint le projet Wasmur. Est-ce que tu peux parler un peu plus de ce projet-là ?
Quel est votre offre ? Qu'est-ce que vous faites chez Wasmur ?
Je vous dis que c'est un projet qu'on utilise pour exécuter WebAssembly côté serveur.
Ce qui nous différencie par rapport à d'autres, c'est qu'on a plusieurs compilateurs et plusieurs moteurs
qui nous permettent d'exécuter WebAssembly de différentes façons.
Soit on peut garder le code exécutable en mémoire et on rend la mémoire exécutable.
Ou alors on peut enregistrer le code exécutable dans une bibliothèque partagée ou une bibliothèque statique.
Et du coup, on peut linker ça à d'autres programmes.
On va assez loin dans le délire de rendre WebAssembly à la fin complètement transparent.
On peut l'utiliser dans tous les cas de figure.
Et on a différents compilateurs, des compilateurs qui sont un peu...
qui vont très peu optimiser le code mais qui vont produire un code exécutable hyper rapidement.
Ce qui est très intéressant pour des usages dans des blockchain ou genre de choses.
Ou alors on a des compilateurs qui vont optimiser de ouf la compilation.
On a pas mal de choses en fait, c'est assez modulable, ça répond à différents besoins.
Et puis dans toutes les open-source, on essaie de collaborer avec le maximum de personnes là-dessus.
On a pas mal de gros acteurs quand même qui commencent à nous utiliser.
On a commencé à faire des sacrés clients, enfin clients utilisateurs pour l'instant.
On a pas encore de produits qu'on vend.
Donc pour l'instant, on a fait deux levées de fonds et puis on vit avec ça.
Mais voilà, à terme, on va quand même proposer des produits pour gagner un peu d'argent.
Et on a tout un système de partnership où il y a des grosses boîtes par exemple qui utilisent notre technologie.
Elles dépendent de ça.
Donc du coup, elles vendent au filet de l'argent tous les mois.
Oui, c'est pour des gens de choses.
Mais c'est intéressant parce qu'on est tous des amourés de l'open-source.
On s'est dit comment est-ce qu'on peut réussir aussi à faire une sorte de modèle économique qui est compatible avec ça.
Et c'est pas trivial.
Mais enfin, par exemple, on a fait l'intégration d'un piton.
Et on a dépassé les 3 millions d'installations pour ces paquets en piton.
Donc c'est à dire qu'il y a quand même beaucoup d'utilisateurs.
Donc on essaie aussi de mettre en place ce truc de Patanaria.
Je ne sais pas si quelques-uns donnent 10 dollars par mois par exemple.
Ça peut mettre la priorité sur certaines features que les gens veulent ou gens de choses.
Donc on essaie d'essayer de pas couler la boîte tout en restant dans l'esprit open source.
Je te laisse la parole Patrick après.
Juste, sur Double Slash, on a invité pas mal de personnes qui font de l'open source.
Et tous nous disent c'est top.
Ideologiquement, tout c'est top, c'est trop bien, il y a une communauté.
Par contre, parfois c'est quand même super chaud parce qu'il faut quand même vivre.
Et en même temps, on boise, on crée des outils, ces outils sont utilisés.
Mais comment on fait pour rentrer dans un modèle économique viable ?
Et vous aussi, vous êtes dans cette problématique là et vous êtes obligé de trouver des solutions ?
Après, on a quand même des gens de talent en interne qui sont capables de trouver des idées de produits qui sont exceptionnelles.
Donc je pense qu'on en a un modèle, on entraîne de développer un modèle économique un peu assez standard dans l'idée.
C'est qu'on a vraiment le runtime qui va être open source.
Tous les outils qu'on fait sont open source, ils le resteront toujours.
Mais on va vendre du service autour de ça et c'est ça que ce sera d'ailleurs gratuit pour la plupart des gens,
mais pour certains utilisateurs, ça va devenir payant.
Et normalement, ça devrait bien marcher.
La projection, on va payer à scale.
Ouais, de toute façon c'est ça.
C'est ce que j'allais dire exactement la même chose que toi.
C'est ce qu'on a reçu, plein de gens qui nous disent bah l'open source c'est cool, mais c'est pas simple de gagner de l'argent.
Mais souvent, ouais, les solutions c'est du sponsorship après de l'assistance payante pour les utilisateurs.
Les grosses boîtes n'hésitent pas du tout à prendre de l'assistance pour avancer plus vite.
Ça, ça marche ou sinon après, ouais, la formule classique où tu vas avoir une version gratuite et après d'autres versions où tu as des trucs en plus.
C'est à peu près toujours la propre, les mêmes solutions, mais ouais, c'est jamais très simple,
même si on est tous d'accord pour dire que l'open source, si il n'y avait pas d'open source, on n'en serait peut-être pas là aujourd'hui au niveau informatique.
Avec les partenaires, là, on arrive à payer un salaire, mais c'est pas ça qui va nous permettre de faire grandir la boîte.
Là, vous êtes combien aujourd'hui ?
On est 1, 2, 3, 4, 5, 5, peut-être 6, bientôt.
Je crois que d'ailleurs.
Là, on est en train d'embaucher pas mal d'ailleurs, donc si vous voulez nous rejoindre, c'est le bon moment.
Oui, justement, oui, vous embauchez sur quel profil développeur ?
Alors, des développeurs, oui, beaucoup, des gens qui connaissent la compilation POSIX PARKER, les Pernels, les VM, la virtualisation.
C'est vraiment...
Ouais, on a des profils un peu compliqués à trouver.
Et puis, on prend en remotes, en fait, donc on n'a pas de locaux, on est 100% décentralisés.
Donc ça, ça aide à retrouver des gens un peu partout.
Ouais, ça ouvre pour rechercher des profils très précis comme vous.
Ça ouvre quand même pas...
Là, c'est le monde en plus.
Et aujourd'hui, la boîte, elle tourne en grosse partie avec des devs, on va dire des devs ou des gens techniques,
ou vous êtes déjà à un stade où vous êtes obligé de vous structurer,
de vous organiser avec un service market, les choses comme ça,
ou essentiellement, c'est quand même des techs ?
On a essentiellement des techs, on a quand même un lead product manager, on a un CEO.
Donc, non, on est en train de se structurer, on est en train de grandir.
Et en fait, le marché, c'est en plein ébullition, et ça, ça nous va très, très bien.
La grande difficulté, en fait, c'est ce que j'ai rencontré dans plusieurs startups que j'ai fait avant.
C'est que nous, on propose la technologie, en fait.
Personne n'a envie d'acheter une technologie en soi, ils ont envie d'acheter un produit,
et c'est ça qu'on peut vendre.
Et on a pas mal de gros acteurs qui utilisent notre techno, qui eux se font un blé colossal,
et du coup, on récupère pas là-dessus.
Donc, on essaie de se positionner pour avoir des produits qui seraient nécessaires pour eux, etc.
Donc, mais ça, vraiment, enfin, je peux pas dévoiler maintenant,
mais vraiment, ça va bien.
Oui, et bien, nos problèmes.
Nos problèmes avec ça.
On comprend.
Très bien, excellent.
Et où est-ce qu'on peut te retrouver ?
T'as un GitHub, t'as un Twitter, t'as quelque chose comme ça,
si on veut suivre vos projets ou te suivre un titre perso.
Alors, titre perso, le plus simple, c'est sur Twitter.
C'est là où j'ai le plus d'audience.
Mon identifiant, c'est mnt underscore io.
En fait, c'est comme mon site mnt.io.
Et puis, le nickname de Wasmer, c'est Wasmer IO, donc pareil.
Et puis sur GitHub, c'est Wasmer IO aussi pour l'organisation.
Ok.
Ok.
Et est-ce que tu voudrais rajouter quelque chose avant qu'on termine l'épisode
sur WebAssembly sans dire le mot de la fin, mais WebAssembly,
qu'est-ce que tu voudrais rajouter ?
Moi, j'ai vraiment la vision.
C'est hyper intéressant.
C'est vraiment le truc qu'on attend depuis longtemps, en fait.
Il y en a beaucoup qui compartent ça à Java.
En disant, c'est la même chose que Java.
On compile une fois, c'est exécut partout.
Et c'est vrai et pas vrai, parce que déjà, la JVM est extrêmement complexe.
Là, WebAssembly a une instruction beaucoup plus réduite.
Et puis, surtout, c'est déjà le résultat d'une suite d'outils, de compilateurs et tout ça.
Donc, c'est déjà quelque chose d'extrêmement optimisé.
Et en fait, ça marche beaucoup mieux que Java.
Ça peut s'intégrer vraiment partout, parce qu'on peut, comme je disais,
on a intégré WebAssembly dans Python, HP, Ruby, etc.
Là, où on a beaucoup de mal à interfacer Java avec Gini peut-être,
mais c'est vachement plus compliqué, et c'est beaucoup plus lourdain.
Et puis, la réalité, d'ailleurs, fait qu'on a une version de la JVM par logiciels,
parce que si on change quelque chose de tout qui pète.
Donc, voilà.
Donc, il y a vraiment ce côté universel et versatile qui est extrêmement intéressant.
Et je vois aussi beaucoup de cas d'usage dans tout ce qui est gros réseau,
tout ce qui est edge computing et genre de choses.
WebAssembly est tellement petit et léger qu'on peut même le mettre
sur des petits objets connectés.
Je sais que la IoT, c'est vachement trending, mais...
Enfin, je vois, le runtime, Wasm3, Wasm3,
eux, c'est un interprèteur, c'est pas des compilateurs.
Donc, c'est plus lent, mais par contre, on arrive très bien
à le mettre sur des petits USB 32, des Arduino, des machins comme ça.
Et ça s'exécute très, très bien.
Et ça, c'est quand même hyper intéressant de se dire qu'on a le même programme
qui peut tourner côté navigateur sur des petits composants avec 64 kilomètres de mémoire
ou même des serveurs ou du edge computing ou des choses comme ça.
Et c'est une technologie, du coup, qui est extrêmement enthousiasmante.
Et les faits, se soient faits en open source, c'est contrôlé par personne.
Ouais, je trouve ça assez fantassement comme ça.
Ouais, on voit que c'est super enthousiasme sur la techno.
Ça donne vraiment envie de s'y mettre.
Oui, puis on a besoin de beaucoup de monde.
Je trouve que tout le monde peut apporter sa pierre.
Aussi bien sûr, quand je parle de WasmPak ou WasmBiGen, c'est des choses assez haut niveau.
On veut générer des APIs pour sortir un langage.
Mais on peut très bien aussi contribuer à la technologie
si on s'y connaît juste en carnet ou en virtualisation.
Ça touche un public super large.
Moi, qui suis un amour de l'open source,
et tous les multiples projets que j'ai fait en arrière,
j'aime vraiment bien voir toutes ces communautés s'y retrouver et collaborer.
Je trouve ça hyper enthousiasme.
J'ai très bien vendu le truc.
Tu l'as très bien vendu.
Mais c'est top.
Parfait.
Un grand merci Yvon d'être venu sur WSLash,
nous parler de Wasm et de WasmR.
On mettra toutes les liens qu'on a évoquées.
On les mettra tous en commentaire.
Dans la description.
Si vous êtes arrivé jusqu'à là, nous mettre un petit like,
un petit commentaire, ça fait toujours plaisir.
Patrick Yvon, un grand merci à nous.
A bientôt.
Merci à vous.
A bientôt.
Ciao.
Ciao.