
PWA Builder avec David Rousset
Durée: 68m56s
Date de sortie: 21/09/2022
Un épisode avec un invité, David Rousset, program manager chez Microsoft et coauteur de BabylonJS. Avec lui, nous allons parler de PWA Builder, un service pour nous aider à publier les progressives web apps Retrouvez toutes les notes et les liens de l'épisode sur cette page : https://double-slash.dev/podcasts/pwa_builder/
Bonjour à tous, bienvenue sur ce nouvel épisode de Double Slash.
Je suis Patrick et comme d'habitude, nous sommes avec Alex.
Salut Alex.
Salut Patrick, salut tout le monde.
Et aujourd'hui, nous avons un invité et c'est David Rousset.
Donc, bienvenue David.
Salut à tous, merci de m'inviter.
Voilà, donc un épisode spécial où on va parler de Progressive Web App et de PWA Builder.
Donc, t'es venu pour nous parler de ça, David.
Et on va te laisser donc te présenter pour commencer.
Voilà, qu'est-ce que tu fais dans la vie ? D'où tu viens, ton background ?
Moi, j'étais développeur depuis tout petit.
J'ai des cheveux grézonants, donc j'ai commencé à longtemps.
Fais 22 ans que je travaille chez Microsoft et ça fait 7 ans que je suis directement
relié à ce qu'on appelle l'engineering ou corp.
Vous savez, il y a des filiales, il y a corp.
Donc, ça fait 7 ans que je travaille pour eux en full remote.
Donc avant que ça soit vraiment à la mode avec grâce ou à cause du Covid.
Et j'étais dans les équipes d'engineering Windows avant, donc on va parler de cette
époque-là, ce que PWA Builder était attaché à ça.
Donc, je géré un projet Open Source, ce qui s'appelait PWA Builder.
J'ai créé un autre projet connu qui s'appelle BabylonJS, qui est un moteur 3D sur le web
GL, WebXR, etc.
Donc, ça, c'est ce qui m'a permis, mais aussi d'être connu en la communauté web.
Il y a une équipe complète dédiée à Microsoft qui travaille dessus d'ailleurs, en partant
de zéro.
Donc, les pêtes projects sur la semaine, ça peut se transformer des fois en trucs qui
sont utilisés.
Et aujourd'hui, sinon, ce qu'on appelle la DevDiv chez nous, donc Developer Division.
Donc, c'est ceux qui s'occupent de Visual Studio, Visual Studio Code, GitHub et certains
services Azure Pass.
Donc, plateformes Azure Services comme Azure Function, Statik Web App, les trucs comme
ça.
Et moi, je m'occupe de la Developer Experience autour de Microsoft Teams.
Donc, nous, en fait, on agit comme des espèces de consultants pour aider des fois d'autres
organisations Microsoft, puisque nous, on a l'habitude de parler au Developer avec
GitHub, Visual Studio.
Enfin, c'est notre audience et puis, on est nous-mêmes développeurs, même si moi,
je suis programme manager, je continue le coder.
Et du coup, il y a des organisations qui, des fois, on a mal à comprendre ce que c'est
un développeur.
La Developer Experience, Longboarding, tu vois, le passé.
Même chez Microsoft.
Oui, parce qu'en fait, il y a des gens, des fois, qui ont un focus très spécifique
sur le...
Teams, par exemple, ils vont surtout penser aux utilisateurs, aux admins.
Mais quand il s'agit de l'extensivité, en fait, des fois, ils n'ont pas forcément
l'habitude d'engager une communauté de développeurs, en fait.
Donc, on va les les aider à leur dire.
Je pense que tu vas dans une mauvaise direction, enfin, à l'Américaine, il faut toujours
que ce soit très positif.
Oui, il faut faire mieux.
Donc, voilà, aujourd'hui, je m'occupe beaucoup de les applications dans Office et qui sont
des web apps aussi.
Donc, beaucoup de web.
Moi, ça fait, j'ai commencé comme tout le monde à faire des trucs type C++, C-Sharp,
.NET, etc.
Et ça fait pas mal d'années que je fais quasiment du web.
Ok.
C'est fait juste une à partait.
Tu parles de développeurs expériences chez Microsoft.
Mais est-ce que ça fait longtemps qu'ils travaillent sur les outils open source, tout
ça ? Ou c'est assez récent ?
Parce qu'on voit avec, enfin, en tout cas, aujourd'hui, ils sont très présents avec
Git, tout ça, Open Source, PWA, Builder, tout ça.
Est-ce que c'est récent ou alors avant juste, ils en parlaient pas, en fait, de tout ce qu'ils
faisaient ?
Nous, quand on a commencé Babylone, c'était pas forcément bien vu à l'époque pour
te dire.
Donc, là, on l'a commencé en 2013, je crois.
On a commencé.
Et il y avait une filiale de Microsoft qui s'occupait de l'Open Source.
Parce que pendant longtemps, Microsoft avait très peur de l'Open Source du mode de fonctionnement
et eu un gros virage avec le changement de CEO qui est, on n'est pas c'est Steve
Balmer à Satya Nadella.
Après, ça se voyait vraiment sur la communication.
Excuse-moi de te couper, mais enfin, c'était flagrant.
Le shift qu'il y a eu après l'air Balmer, c'était, mais c'était rien.
Enfin, il y a eu vraiment un shift et là, on voit qu'ils sont vachement plus investis
dans l'Open Source.
Clairement.
Oui.
Et pour des raisons pragmatiques, en plus, c'est-à-dire que Satya arrivait et venait
lui s'occuper de la branche Azure Cloud.
Donc, c'est devenu le patron de toute la boîte.
Et lui, il était assez pragmatique.
Il s'est dit de toute façon, on ne peut pas, la meilleure façon de travailler avec
tous les développeurs, c'est d'aller là où ils sont, de travailler de manière ouverte,
etc.
On continue à avoir des produits fermés, Windows, etc.
Mais voilà, on a trouvé un meilleur équilibre et il n'y a aucun souci pour travailler en
Open Source.
Le seul problème, c'est qu'il y a des équipes qui ne savent pas ce que c'est l'Open Source.
Moi, ça fait longtemps que je suis dedans et ils pensent que si je mets mon code sur
un repo GitHub, voilà, je fais de l'Open Source.
Non, en fait, tu donnes ton source, mais ça ne sert à rien si tu ne suis pas à les
issues ou les pires, si tu n'animes pas ta communauté, si tu ne prends pas en compte
les feedbacks.
Et ça, c'est un vrai travail.
En fait, c'est sous-estimé par les gens qui ont eu l'habitude d'être dans leurs
petits cocon magiques.
Donc voilà, donc ça, je vais participer à cette transformation et je suis souvent
consulté grâce ou à cause de les double builders qui ont bien fonctionné et de
Babylon.js sur, tu peux nous expliquer comment on fait l'Open Source.
Et en fait, ce n'est pas forcément compliqué, mais il faut y aller vraiment, il faut travailler.
Après, je pense que tu dois faire beaucoup d'acculturation.
De dire, OK, on va tout reprendre de scratch et peut-être leur expliquer ce que pour quelqu'un
qui n'a pas cette culture-là, ça doit être très compliqué de suivre ce shift-là.
Oui, puis je ne sais pas si vous travaillez dans des grandes boîtes aujourd'hui, mais
des fois, il y a des gens, ils font sur des checkboxes.
C'est genre, on m'a demandé, travaille en Open Source, j'ai mis mon code sur un repo,
checkbox, je vais dire à mes chefs, j'ai fait l'objectif.
Et moi, ça m'énerve en général.
Donc, j'ai dit, non, moi, souvent, je dis même à des équipes, ne faites pas de l'Open
Source, il vous fait à moitié, c'est contre-productif, c'est génére vachement de frustration.
Enfin, donc, donc, je préfère gérer des gens qui disent, c'est chiant, vous ne donnez pas
que c'est au source code et que de le mettre à moitié et en fait, OK, tel source code,
mais finalement, on s'en fout de ton avis, parce qu'on ne fera jamais quoi que ce soit
sûr.
Souvent ce qui est sous-estimé, c'est la gestion derrière de la communauté.
Des issues, tout ça.
Et ça, c'est le plus gros travail en plus de l'avoir le code source à la base.
Et c'est vrai que comme tu dis, si tu mets sur GitHub et tu as des issues et tout, mais
tu réponds jamais ou tu mères jamais les PR, c'est pire que d'autre.
C'est un mauvais signal.
Et on l'a eu sur Babylon.
Babylon, c'est très particulier, c'est de la 3D.
Donc, il faut voir, ça devient un niche pour voir des gens capables de biomotor.
On a fini par l'avoir, mais au démarrage, moi, c'était mon premier code source.
Je me disais, ben, tel code source, oui, mais en fait, les gens ne comprenaient rien.
C'est pas suffisant, bien sûr.
La doc, la communauté, les change, j'ai une question, j'ai pas compris.
Non, mais c'est clair.
Il y a tout ce qui gravite autour, qui est, je dirais même, peut-être aussi important
que le code source.
Ah oui, au moins aussi important si ce n'est plus.
Alors peut-être que votre audience est déjà au fait de ce genre de problèmes, etc.
Mais voilà, certains des fois sous-estiment méchamment l'implication
de un projet open source, c'est pas juste la doc.
Avec la doc, déjà, c'est travail énorme.
Enfin, voilà.
Top, super.
Merci de cette présentation un petit peu globale, mais ce qui pose un peu le décor
pour l'épisode.
Comme on l'a dit tout à l'heure, on va parler de PWA Progressive Web App.
À limite, on avait déjà discuté dans un épisode précédent
avec quelqu'un, avec Stéphanie, qui était venu nous parler des PWA.
C'est un secteur où il se passe beaucoup de choses parce que par définition,
c'est du web.
Le web évolue.
Il y a des API qui s'ouvrent, les navigateurs.
Merci tous les navigateurs modernes qui mettent à jour leur API.
Et on va dire plus ou moins vite, plus ou moins vite, parfois même trop vite.
Mais bon, ça, c'est un autre sujet.
Mais au moins, ça s'est évolué.
Est-ce qu'à la limite, David, on peut discuter un petit peu de l'état des lieux
de des PWA aujourd'hui en 2022?
Et peut-être commencer, Patrick, tu serais chaud pour faire une définition
des PWA globale?
À quoi ça sert, en gros?
Dans où David, je sais pas, peut-être.
La définition, la définition, elle est compliquée parce que
c'est un web, pour retenir web app.
Moi, chaque fois que j'explique, j'ai fait beaucoup de conférences sur le sujet.
J'ai fait beaucoup de rendez-vous aux clients.
Il y a beaucoup de gens qui sont perdus parce qu'ils pensent que c'est
complètement nouveau.
Donc ils se disent, j'ai pas envie de refaire ma web app from scratch
parce que j'ai déjà une web app.
Et non, mais justement, c'est le paix de progressif qui va du coup t'intéresser.
C'est sûr que si tu as déjà une bonne web app, l'idée, c'est d'utiliser des techno
que tu connais pas forcément moderne, qui vont te permettre de bouger progressivement
ta web app vers une expérience de type natif.
En fait, on vise à être en compétition quelque part avec le natif.
Sur plusieurs aspects, c'est la gestion de l'offline, par exemple, sur le mobile.
Tu vois, l'amélioration des performances grâce à la même techno sous-jacente
qui est le service worker.
Et puis la possibilité aussi de pouvoir installer l'app comme une app native.
Donc pour se faire, tu as besoin de décrire un peu ce que fait ton application
et ça, ça va être géré par un manifeste qui va te donner un icône,
les capacités de l'application pour s'intégrer dans le système d'exploitation, etc.
Donc PWA, c'était un terme marketing principalement poussé par Google
dans lequel nous, on s'est ensuite inscrit bien sûr, appliqué.
Mais c'est en évolution permanente parce que c'est de la même manière que tu peux pas définir aujourd'hui
ce que c'est une web app.
Tu peux pas dire, je ne vais pas prendre une liste à la préverse, on va s'addire
que l'utilisation de tous ces API potentiel dans la plateforme web.
Donc PWA, c'est pareil, souvent, malgré tout, pour simplifier,
on dit que tu as une progressive web app, une PWA lorsque tu as un service worker
qui est registré, qui fonctionne, que tu as un manifeste et que tu as un HTTPS.
Donc ça, c'est les trois briques de base qui te permettent en fait de triggers
dans ton navigateur, l'icône qui va dire, tu peux installer ce site.
Quelque part en tant qu'application.
Mais c'est beaucoup plus vaste que ça puisqu'en fait, c'est comme si je vous
demandais, c'est quoi une bonne ou une mauvaise application sur votre mobile.
C'est pas parce que tu te dises le SDK pour faire une application mobile sur iOS
ou Android que forcément, ça va être une bonne application.
Et voilà, donc j'essaie de résumer un peu ce que c'est une PWA.
C'est ça, Proché du Natif avec des fonctionnalités modernes qui sont arrivées
dans le navigateur ces derniers temps, qu'on va certainement déclare maintenant.
Exactement. Après nous, on est aussi bien pas Patrick que moi-même.
On a déjà fait des PWA.
On est plutôt pouchi là-dessus parce qu'on a plutôt un background de développeur web
et justement de tendre vers cette de réduire la limite entre le natif et le web.
On trouve ça super bien et super facile et ça nous évite aussi de...
Mais même pour les clients de faire trois, quatre codes base
différentes, de recoder la même chose.
OK, on le fait une fois, on le fait bien sur du web et on l'intègre.
Néanmoins aujourd'hui, quels sont les points bloquants ou les lacunes qu'on
pourrait avoir sur des PWA ?
Alors, on rattrape pas mal de choses par rapport à une application native.
Quand les gens pensent natifs, ils pensent du coup offline, ils pensent responsif.
Le web était précurseur, il était même en avant sur le natif là-dessus.
Mais ensuite, il y a l'accès à la plateforme au système d'exploitation.
Donc le fait que j'ai mon application qui peut être installée, qui fonctionne en offline,
qui peut s'intégrer de plus en plus dans les paradigmes du système d'exploitation,
fait que l'utilisateur va s'attendre à faire pour la même chose qu'une app native
et l'app native à la désapéie directe.
Le file système, par exemple, ça, c'est pendant longtemps, c'était un truc
un peu quasi impossible à faire sur du web, en tout cas pas super.
Donc maintenant, on a des API qui permettent de gérer le file système, plus ou moins.
On a le Bluetooth aussi qui est disponible.
On peut faire la 3D de la VR, ça va être peut-être de la niche et on peut le faire.
On peut faire du USB, du midi.
En fait, il y a énormément d'API qui nous ont énormément rapprochés du natif.
Qu'est-ce qui nous reste ?
On n'a pas accès direct malgré tout au système d'exploitation.
On va toujours travailler dans la Sunbox qu'est le navigateur.
Du coup, ce qui est bien et pas bien, ce qui est bien, c'est qu'il y a une notion
de sécurité, c'est rassurant pour l'utilisateur et peut-être vos clients
que vous allez déployer l'app en disant, de façon ou on tourne dans le contexte
du navigateur, donc c'est comme une surface d'attaque et même plus réduite
qu'une app qui tourne directement sur le système.
Par contre, l'inconvénient, c'est que si j'ai besoin de faire un appel aux
petites opinions de la dernière API qui vient sortir, je ne sais pas moi, iOS 16,
sort avec la possibilité de gérer leur dynamic Island ou je ne sais pas quoi,
etc. Avant que ça soit exposé pour surtout en venant de la part d'Apple,
parce qu'on va reparler des différents acteurs.
On va en parler.
On va en parler.
Avant que ça soit exposé dans la plateforme web, vous allez attendre longtemps,
mais presque Google, c'est pareil et Microsoft.
C'est à dire que ça va.
On va forcément privilégier pour les trucs dernières générations.
D'abord, le SDK natif et après le souci quelque part ou l'avantage en fonction
des points de vue, c'est qu'on discute tous ensemble pour normaliser,
pour faire un standard au-dessus de ça.
Il se trouve que depuis que tout le monde utilise Chromium,
les discussions ont été beaucoup simplifiées au désespoir de Mozilla et
W3C, mais du coup, ça va beaucoup plus vite.
Mais malgré tout, ça va pas aussi vite que la future qui arrive.
Donc ça, c'est un des premiers inconvénients.
Le deuxième, c'est la performance, même si aujourd'hui,
les navigateurs ont des jiteurs de foot, des moteurs JavaScript de foot,
des moteurs de rendering de dingue.
On a WebGL, WebGPU, on a pas mal de propriétés accélérées en CSS.
Si tu fais bien ton boulot, tu peux avoir des app merveilleuses en Web.
Mais c'est implique de faire bien son boulot.
On en reparlera justement.
Le problème, c'est que JavaScript est monosreddé, toujours par nature.
On a les web-workers qui permettent de
faire un simulacre du pauvre, du multisredding, mais c'est souvent inutile.
Du coup, ça, ça peut être limitant.
Alors typiquement, moi, je pense, mon biais, c'est jeux vidéo.
Le multisredding, c'est un vrai avantage pour pouvoir exploiter au mieux le CPU
justement qui est surutilisé dans les jeux vidéo.
Dans une app Web, la plupart des clients qui j'ai
travaillé ont rarement touché cette problématique du multisredding,
d'autant qu'en plus, moi, j'ai travaillé avec Adobe, par exemple,
qu'on portait pas mal de leur app native vers les PWA.
Via WebAssembly, qui est une autre technologie qui,
elle, pour le coup, avait super vite.
Il y a des moments magiques un peu dans le web.
Il y a des propriétés CSS, il faut 200 000 ans pour l'avoir.
Et WebAssembly, en une année, c'était plié, tout le monde l'avait
accepté et implémenté dans son navigateur.
WebAssembly, ça nous permet de nous approcher du native,
mais il n'y a pas encore vraiment le multisredding dans WebAssembly.
Donc je dirais que le gap entre les deux, c'est fortement réduit.
Moi, dans les discussions que j'ai avec des partenaires chez Microsoft,
ils veulent venir chez nous sur notre store,
parce qu'on en reparlera, on accepte aussi les PWA sur les stores.
Souvent, la discussion, ça devient de plus en plus,
c'est plutôt les compétences de votre équipe que vraiment les limites
de la plateforme, parce qu'à moins d'avoir un scénario très niche de,
à moi, je fais, je sais pas, une app qui a besoin d'énormément de GPU,
d'IA pour faire, je sais pas quoi, quitte.
OK, on va dire, peut-être que là, on arrive au limite du web.
Et encore, on peut y arriver, mais privilégié peut-être le native.
Mais la plupart du temps, pour une app Lambda,
c'est des compétences de l'équipe parce que...
Et si ils ont que des devs si cher, c'est plus, plus ou j'avère,
je vais leur dire, ne pensez pas que le web, c'est forcément facile,
c'est faire une app, en fait.
Une PWA, c'est peut-être la différence principale par rapport à une web app.
C'est une app, et en fait, les gens n'ont pas conscience de ça.
Quand tu fais ton petit site web dans ton coin, je ne veux pas être,
tu vois, 10 ans péjoratif,
mais le set de compétences pour passer d'un site web,
donc qui va être détruit, en fait, au fond de la navigation,
à une app qui tourne tout le temps, qui est optimisée,
aux petits oignons, qui sait gérer le DOM,
où tu comprends toute la plateforme,
c'est un jeu de compétence très particulier.
Et c'est fabriquer une app, voilà.
Ça va être la différence principale.
Après, il y avait un argument qui sortait souvent, il y a quelques années,
c'était les notifications.
Les notifications.
J'ai pas de notification.
Les marketeux veulent que ça.
Et les marketeux, ils voulaient à tout prix des notifications.
Et Apple était, c'était chasse-garder,
c'était un rideau, terminer, on n'en parle pas.
Il semblerait que l'ouverture arrive.
Donc, c'était juste une question de temps.
Mais je pense que tous les autres acteurs ont dû pousser.
Et tu vas peut-être nous en parler, mais Apple ouvre un peu.
Et moi, ce que je vois souvent, c'est...
Alors, même si c'était une limitation psychologique,
une sorte de plafond de verre, mais ils utilisaient cet argument pour ne pas
passer sur des PWA et faire du natif.
Et même, on va dire, les agences qui jouaient du natif et utilisaient
cet argument commercial en disant, oui, mais la non-nétification ne va pas marcher.
Donc, non, pas de PWA.
Qu'est-ce que tu en penses, toi, de ça ?
Ça a été un débat sans fin, parce qu'on l'a forcément eu.
Nous, on est de l'autre côté du miroir, donc côté web.
Donc, moi, je ne suis pas religieux.
C'est à dire que si jamais il y a une résistance forte à aller sur les
techno-webs pour des bonnes raisons, enfin, ça nous fera une discussion
pragmatique, oui, OK.
La télémétrie, quand on a regardé, nous, on accède à toute la télémétrie.
C'est qu'en fait, tout le monde s'en fout de la notification et des
désactifs super chiants, en fait.
Et donc, du coup, c'était plutôt une vision des, comme tu dis, des équipes
marketing ou qui voulaient absolument ça, mais des utilisateurs le désactiver.
En fait, par exemple, j'ai bossé avec Twitter quand j'étais en train de
m'occuper de PWL à Builder et Twitter, par défaut, si tu regardes l'app sur
Android aujourd'hui et Windows, c'est une progressive web app.
C'est eux, ils ont vraiment, c'est l'exemple qu'on donne à chaque fois.
Twitter, c'est quand même une app pas mal utilisée.
Donc, les gens qui disent, oh, mais les PWL, c'est des jouets, ça sert à rien.
On commence à avoir pas mal de gros trucs qui permettent de te contredire.
Et par défaut, effectivement, ils ont peu d'activation, de la
dénotification, parce qu'en fait, ça implique un travail
vachement important de création de confiance avec ton utilisateur.
C'est que si par défaut, tu lui sautes à la gorge en disant,
tu veux les notifications, mais je te connais pas encore,
t'es déjà en train de m'agresser sur les notifications et on fait un dégage.
Plus jamais, il va aller voir l'option et tu as perdu une opportunité de
justement potentiellement améliorer son expérience.
C'est ce que c'est le discours des marquetteux.
C'est la voilà les marquetteux voir leur propre intérêt.
Par contre, aujourd'hui, on va dire, c'était peut-être vrai,
il y a cinq, six ans sur les notifications.
Tout le monde ne jurait que par ça.
Aujourd'hui, on est spammé, on peut dire le mot, on est spammé de
notification dans tous les sens.
Et aujourd'hui, l'utilisateur, il dit non, mais moi, je bloque tout.
Je bloque tout.
La réalité, elle est là.
C'est pour ça que nous, les UX,
designers et qui ont bossé et disaient,
c'est une relation de confiance que tu dois mettre en place.
Et il fallait trouver des paternes en fait de voilà,
ça fait un moment que tu utilises notre progressive web app.
Saches que tu devrais être intéressé à tel et tel sujet.
Tu pourrais tu vois, tu vas cesser.
Il y allait doucement de manière smooth.
Tu vois donc et effectivement, il y avait Apple qui ne supportait pas.
Alors il y avait des palliatifs où on pouvait
prendre la webvue, prendre la proébope et faire des ponts avec le natif.
Un peu comme le faisait à l'époque, Cordova, ce genre de chose.
Bonne gaffe.
Mais c'est vrai que c'était pendant longtemps un frein psychologique,
comme tu le disais avant que et puis il y en a qui étaient fridue.
C'est à dire que tant qu'il n'y avait pas des gros qui y allaient en disant,
en fait, c'est la théorie du mouton.
C'est OK.
OK. Tout le monde y va.
Donc j'y vais.
Il y a un phénomène d'entraînement qui s'est passé clairement.
Et Apple, effectivement, Apple, c'est le vide un petit canard.
Mais parce que
souvent dans le monde du web, on est un peu dans le monde des bisounours.
Moi, j'ai été souvent des confs comme Paris Web et tout.
Ça me fait vachement bien parce qu'il y a une très bonne ambiance,
une culture vraiment différente, etc.
Mais en fait, les Google, Microsoft, même Maudia, quelque part et Apple,
ont des business models qui leur sont propres.
Donc des intérêts aussi qui leur sont propres.
Apple, oui, il voit forcément.
Il faut être divergent du web.
Ah, ben oui, clairement.
Donc Google, qui est quand même celui qui a le poussé le plus web
les dernières années avec Chromium et Chrome, ils ont des guerres internes entre.
Oui, mais enfin, si tu vas trop loin sur la plateforme web,
quelque part, tu rentres en compétition avec Android.
Nous, on est ramassés sur le store.
En fait, l'avantage, c'est qu'on est plutôt ouvert en disant,
on va plutôt pousser et faire un peu comme Macdo, vient comme tu es.
Tu vois, c'est et Apple, clairement, c'est la poule aux yeux d'or, l'or store.
Donc si tu peux bypasser l'or store avec un truc de qualité suffisante pour
tu aller vers l'or store, oui, c'est l'empêche à tout prix.
Donc et puis on voit bien aussi la querelle qui a eu avec Fortnite et avec les paiements
en interne demain ou demain, on fait des PWA.
Je mets mon propre système de paiement et je bypass totalement les la la DIM.
Et de chez Apple et ça, en fait, un client aujourd'hui, il comprend tout de suite.
Il fait son calcul, il comprend très, très vite.
Ah, oui.
Et d'ailleurs, c'est marre que tu partes tâcher à nous, Microsoft.
On a un service qui s'appelle
le cloud gaming de la Xbox.
D'ailleurs, l'interface au-dessus, c'est Babylone.
C'est pour ça que je connais bien.
Donc pour les touch controls, c'est le mode que l'on utilise dessus.
Et on a sorti une PWA pour iOS.
Donc tu peux installer pour que tu puisses broser les jeux,
streamer le jeu depuis ton iPhone.
Et moi, je me suis toujours dit Apple un jour, là, ils sont un peu coincés.
Il reste striket, bien sûr.
Un jour, ils vont peut-être faire une liste de les domaines où je désactive.
Finalement, les cheetures, ça va râler comme pas possible.
Mais ils veulent sur la plateforme et puis ils ont cette image un peu de
rêver de ce qu'ils veulent.
Il n'arrive pas grand chose.
Et en fait, après, c'est là, c'est la prophétie.
Je sais que ça n'engage que moi.
Mais en fait, ce modèle-là ne pourrait n'est pas
tenable dans le temps à un moment donné.
Ça, ça, ça, ça, ça, tout à une fin.
Et je pense comme tu dis, il y a des domaines où ils vont être obligés de lâcher.
Parce qu'en fait, ils seront en conflit avec en interne, ou à où il y aura tellement
de pression autour et là, on le voit sur sur les notifications.
Ils ont, ils ont fait preuve d'ouverture parce que tout le monde à côté,
ils en fait, ils sont devenus des petits vilains canards.
Et à un moment donné, ils sont, ils sont obligés de le faire.
Ils le font à contrecoeur, je pense, mais ils le font quand même.
Et je pense que ça sera pareil pour le paiement.
C'est juste une question de temps.
Oui, et puis c'est la pression.
C'est à dire que quand les utilisateurs vont commencer à dire,
je vais sur tel site web et je vois qu'on copain, il a un Android ou je ne sais pas quoi.
Il a, tu vois, grâce au paix de progressive, on va pouvoir activer des trucs qui sont
mieux sur un Android que sur un iPhone.
Typiquement aujourd'hui, un truc que tu peux
faire facilement sur un Android, c'est du Web XR, donc faire de tout ce qui
réalité augmenter directement dans le navigateur sur l'iPhone.
Non, forcément, ça ne veulent pas du tout activer
genre de trucs. Donc je pense que c'est une pression qui va venir des utilisateurs
parce qu'ils sont quand même très sensibles
au retour de leurs utilisateurs qui sont leurs fans absolus.
Mais c'est ce qu'ils disent.
C'est ce qu'ils disent.
Oui, oui, ils communiquent beaucoup dessus.
Mais ils écoutent vraiment ça après.
Ça, je ne sais pas, je ne sais pas.
Mais c'est vrai que c'est de cette manière là qu'on a réussi à les faire
plier de temps en temps.
Ils ont fini par implémenter Web Audio, WebGL2 comme ça.
Oui, bah semblent, ils ont été assez vite,
une manière étonnante.
Mais c'est très difficile.
Moi, j'ai essayé de discuter avec eux.
Donc moi, j'avais besoin de discuter avec tous les acteurs.
Donc le projet que je gérais, je travaillais Google puisque
notre plateforme a produit aussi des...
On va reparler de ce que fait PwLabilder, on va travailler Google avec Samsung,
pas avec Mozilla beaucoup malheureusement, puisqu'en fait, ils n'ont pas vraiment...
On parlait des limitations, Firefox a vraiment lâché l'affaire
sur tout ce qui est progressive Web App.
Et avec Apple, parce qu'on voulait chiper dans leur store et on voulait savoir
si quelle était la vraie politique, c'est parce qu'en fait,
ce que tu lits la politique du store sur les apps HTML5, ils appelaient encore ça.
C'est pas très clair.
C'était ce que si je le fais, il y a des gens qui arrivaient à passer dans le store.
Donc d'autres qui se faisaient straquer d'entrée de jeu, d'autres qui passaient
une semaine après ils se faisaient straquer.
C'est super pénible en fait de pas avoir de clarser sur ce que tu peux faire.
C'est quoi la vraie guideline ?
C'est quoi la frontière ou à ne pas dépasser ?
Là, c'est un peu des terrains mouvants.
Et donc le Web, c'est ça qui cool, c'est que
quand tu es sur le Web, c'est bien ou c'est pas bien, mais tu fais ce que tu veux.
En fait, et c'est un peu un mix des deux, les PWA, c'est qu'on arrive à réduire cette frontière.
Donc de plus en plus de clients, je suis pas étonné que vous avez ces demandes-là
si intéressent, mais ils ne maîtrisent pas beaucoup le sujet.
Donc si vous maîtrisez, je pense que c'est une bonne carte à jouer dans votre CV.
Ouais, après, nous, on est convaincu aussi qu'il y a une grosse majorité des applications
qui sont sur le store qui peuvent être faits en PWA parce qu'il n'y a pas de
choses incroyables dedans et que ça coûterait beaucoup moins cher.
Les mises à jour seraient plus simples, pas besoin de validation de store, etc.
Beaucoup moins cher, beaucoup moins cher.
Je mets un bémol, ça va dépendre du niveau de qualité que tu vises
et des compétences de l'équipe parce que les deft-opguns qui sont capables
d'atteindre le niveau de qualité d'une app native, ça require quand même pas mal de boulot
parce que c'est super cadré.
Ça, c'est l'avantage des natifs.
Tu aurais parlé des inconvénients et des avantages de natifs.
C'est super cadré.
C'est sur iOS, tu as un set de contrôle, tu vois, qui vont être nickel, super optimisé, etc.
Sur le web, c'est open bar.
Donc on va commencer, tu veux faire du règles, du angular, du vu, du vanillat, du machin.
Enfin, tu vois, c'est déjà, il faut trouver, définir tout au même tas stack,
faire tes contrôles peut-être tout au même temps, en tant bien optimisé.
Enfin, le coup, c'est pas difficile à évaluer.
Mais par contre, tu as une seule code base, ça, c'est sûr.
Et il y a plein de cas où ça coûte moins cher.
Moi, j'ai eu plein de cas où des apps, par exemple, des clients où il s'en fout d'avoir
le look and feel à US Android, Windows, parce que du coup, un autre inconvénient,
c'est que tu as le même UX souvent.
Tu peux triquer pour essayer d'adapter tes feuilles de style par plateforme,
mais souvent, tu as le même look and feel.
Il y a plein de clients pour les applications Line of Misses-Dest internes,
ils s'en foutent.
Et là, ça coûte beaucoup moins cher, effectivement.
Total, mais sur OK, ils veulent créer un peu une brand,
tout ces brandés à leur truc à eux.
Après, il y a aussi beaucoup d'applications qui sont hyper basiques sur les stores,
faire des To Do List ou des trucs comme ça où ils ont pas besoin d'avoir du CPU.
Ils ont pas besoin.
Et en fait, pour moi, c'est over engineering total
d'entretenir deux, trois code bases parce qu'à un moment donné,
ils sont sur Android, après, ils sont sur Apple.
Et après, ils se rendent compte qu'en fait, leurs clients, ils leur demandent du web
parce qu'ils voudraient être sur le desktop.
Et ils refont une troisième et en fait, ils font trois fois la même chose.
Et là, tu dis, oui, mais ça m'a l'été pensée au départ.
Si si tu t'es déposé les bonnes questions, tu serais parti sur une PWA
et en fait, tu n'aurais pas eu tous ces problèmes là.
On est entièrement d'accord.
Et c'est pour cette raison que notre partenaire et qui on engage maintenant
par défaut, leur mindset, une fois qu'il passe par notre moulinette de conviction,
c'est qu'ils pensent PWA pour cross-platformes et souvent, par contre,
iOS, une branche à part parce que c'est vraiment casse-pied des fois d'avoir le support sur iOS.
Ils disent, OK, on fera une app, soit hybrid, ça, ce n'est pas très clair.
S'il n'y a Apple, l'autorise donc plus de faire un app hybrid, c'est-à-dire WebU
plus d'une native, soit soit full native.
Et donc, du coup, comme tu le dis, on essaie de mieux contrôler les coups,
plutôt de faire ça trois fois.
On va le faire deux fois.
Et sachant que le Web, en plus, demain, il y a un nouveau device qui arrive.
Il y a de fortes chances qu'il ait un navigateur Web, en fait, tu vois,
et de fortes chances que ça soit du Chromium.
Donc, en fait, boum, d'entrée de jeu, tu as des apps déjà supermoderne dessus.
Bon, je crois qu'on a bien parlé des PWA.
On a bien fait le point.
Je pense qu'on est tous là, tous les trois, on est tous d'accord.
On est pro.
Par contre, on va parler du tout le monde comment on peut les faire
et comment on peut avoir un outil qui nous permet d'aller sur les stores.
Parce que, nativement, en fait, même si j'ai codé mon app,
elle est compatible PWA, ce qui veut dire que j'ai installé,
j'ai rempli, on va dire, tous les critères.
Pour aller sur les stores, c'est pas suffisant.
Et c'est là où PWA, Blider, rentre en scène.
Et du coup, David, est-ce que tu peux nous en parler, dire comment ça marche,
comment ça fonctionne, qu'est-ce que ça fait exactement ?
Oui, alors c'est né d'un besoin des développeurs qui ont discuté,
qui nous disaient, OK, j'ai compris, service worker, le manifeste,
donc le manifeste qui va décrire vos icônes, etc.
Le comportement de l'application, potentiellement pour ceux qui savent pas,
ou que vous installez une PWA, par exemple,
vous pouvez envoyer des fichiers ou faire communiquer deux app en train
avec des contrats de partage, donc on appelle web share,
on a les notifications.
Tout ça, en fait, c'était des fois un peu compliqué pour des web développeurs classiques,
de basculer, comme je le disais, dans le monde type natif,
quelque part des gens qui venaient du monde du mobile, ils connaissaient ces principes-là,
mais ils étaient développeurs natifs.
Donc PWA, Blider au débarrage, c'était aussi pour les aider à les édicuer,
en partir de zéro, devoir donner des codes simple, de générer un manifeste,
parce qu'il y a un truc qui est très pénible avec les manifests,
c'est qu'en gros, chaque plateforme décide d'avoir sa taille d'icône à lui,
donc je ne sais pas comment les yeux expliquer, mais je ne sais pas,
il y en a, il va dire...
Vous pouvez y avoir le problème.
Oui, vous pouvez y avoir le problème.
Donc ça, c'est un truc chiant, vous voulez l'automatiser,
et pour finir, pour aller dans les stores,
chaque store a son propre format de package,
donc sur Android, ça a été longtemps APK, ça a changé,
je ne me souviens plus maintenant, c'est un nouveau format,
donc on a dû s'adapter.
Chez nous, c'est un autre format chez Microsoft,
tu vois, et etc.
C'est-à-dire qu'on a travaillé au Oculus aussi,
récemment au Oculus, supporte les PWA,
donc pour des apps très particulières,
ça va être plutôt des apps de type VR, forcément ou des jeux,
mais on s'était dit, ce truc-là, côté DevWeb,
tu as l'habitude de publier sur ton serveur web, ton app,
et aller dispo immédiatement,
les mecs, ils n'ont pas du tout le mindset de dire,
qu'est-ce que je vais m'embêter à aller publier sur un store
qui me pose plein de questions, qui me demande un compte,
des certificats, des validations, etc.
J'ai un bug sur ma prod, je dois faire une request,
ça doit être validé,
ça doit être...
Wow, vous n'avez pas l'habitude.
Oui, donc pas l'habitude.
Alors, l'avantage d'une PWA,
c'est pour ça que la PWA, on avait pas mal de trafics,
on en a toujours, c'est qu'une fois que je n'ai pas 4G,
donc on prend votre PWA, on va l'analyser,
on va vérifier si elle correspond à des critères de qualité.
C'est super dur à évaluer la qualité,
puisque c'est très subjectif,
mais il y a quand même une partie technique.
Donc on fait une évaluation type Lighthouse,
on utilise des soft comme ça en arrière-plan,
qui vont te checker si tu as un service worker,
s'il est bien registré,
si quand on coupe le réseau,
si ton TAPW à se comporte bien,
on va vérifier ton manifeste,
à quel point il est bien rempli, etc.
On va donner un score,
donc ça c'est moi qui voulait absolument gamifier,
avec mon background gamer,
et chaque clé Dev ils aiment bien de dire,
ah comment je peux gratter un score super,
c'était plutôt pour les inviter à améliorer.
Non, ça marche, ça marche, on te valide le truc,
on a joué avec et on gratte, on gratte, on gratte.
Parce qu'en fait, de l'autre côté du cadran,
on avait les gens responsables de notre store,
par exemple, qui voyaient ça d'un mauvais œil,
de dire, si tu mets des craps app, un web un peu pourri,
ça m'intéresse pas.
Donc on voulait un peu filtrer en amont,
et sans non plus imposer,
c'est-à-dire que si tu es envie de mettre une craps app
et que tu penses que tu vas faire du business avec,
moi je ne veux pas non plus t'empêcher de le faire.
Mais par contre, si je te fais des petits warnings,
en disant, bah tu sais, si tu mettais le contrat de partage,
tu pourrais engager davantage tes utilisateurs, etc.
Donc ça, Pdoula Builder,
il essaye d'éduquer ou faire un mesure en analysant ton app,
tu rentres une URL au démarrage, il analyse ton app,
et ensuite il te propose plusieurs plateformes en output,
la plus populaire c'est Android,
ensuite c'est Windows,
et après il y a des autres iOS,
iOS, bon, on a une forme de support,
il y a beaucoup de demandes,
mais il y a beaucoup de rejets, donc à nouveau on en parlait,
et Oculus.
Et donc on te donne un package,
et après que ce package,
on te donne une doc en disant,
bah maintenant tu as ce package là,
déjà tu peux le siloader sur ton Android
ou ton machine Windows pour vérifier un peu le comportement,
et une fois que tu es content,
bah tu peux l'envoyer vers le store,
et une fois qu'elle est validée dans le store
que soit Microsoft ou Android,
dans le Play Store,
la beauté comme on dit à les américains,
c'est que tu peux,
imaginons que tu as un petit bug de CSS
remonté par un utilisateur en disant,
je sais pas moi c'est pas bien aligné sur mon Samsung Vdull,
etc.,
tu peux fixer ça sur ton site,
parce qu'en fait,
le package, je contente de référencer,
et ensuite d'installer la PWA
comme si tu le faisais depuis une navigateur,
c'est-à-dire que pour l'utilisateur,
il y a plein d'utilisateurs,
je sais pas si vous les remarquez,
mais comprenne pas ce truc dans le navigateur
où je peux l'installer l'app depuis le navigateur,
ça leur parle pas,
pour eux une app, ça vient du store,
donc c'est pour ça que...
Bien sûr,
pour le coup,
il faut vachement éduquer en disant,
ok mais je suis allé sur le store,
je l'ai pas trouvé,
non, mais en fait,
c'est pas comme ça que ça marche,
et il faut éduquer encore.
Et il faut éduquer,
il faut qu'on a meilleure,
moi c'était un de mes cheveux,
un de mes cheveux de show,
je suis pas de bataille,
je suis pas de bataille.
Pour convaincre les équipes de Edge,
avec qui j'ai beaucoup travaillé pour améliorer l'UX,
je dis c'est pourri l'expérience aujourd'hui,
un utilisateur de l'Andai,
il comprend rien,
c'est nous,
on est des pros du web,
on sait de quoi ça parle,
ça va nous parler,
mais il faut améliorer
à nouveau la relation de confiance avec l'utilisateur,
pourquoi ils sont flippés du web,
on les a éduqués à dire,
méfie-toi du web depuis des années,
et donc là on leur dit,
j'installe une app depuis le navigateur,
donc par défaut,
non je les touche pas.
Par contre,
ils ont une relaxation de confiance avec les stores,
qui va faire ce travail de filtrage,
mais au final c'est exactement ce que fait dans le KPW builder
pour une app par excellence sur Windows,
il va appeler l'API de Edge,
qui va registrer l'application,
et l'installer sur ta machine de manière transparente.
Donc tu auras exactement la même expérience
que si tu l'avais appelée depuis le navigateur,
sauf que ça vient du store,
et par-dessus du coup l'avantage de venir du store,
c'est que tu peux aussi faire des reviews sur le store,
ce que tu peux pas faire,
si tu installes depuis le navigateur,
parce que je voulais travailler,
je sais pas où on en est,
sur des appels de reviews aussi,
qui seraient intégrés au niveau de la plateforme web,
mais là ça vient du store,
donc du coup tu peux aussi vérifier les avis sur le store
de la progressive web app.
Par contre la mise à jour,
comme au final ça vient de ton site web,
c'est décoré les stores,
t'as pas besoin comme tu le disais,
je fais une petite mise à jour de CSS,
de demander la permission à Microsoft, Google ou Apple,
de faire ta mise à jour de CSS,
et de checker que tu fais pas quelque chose de vide.
C'est super intéressant,
en fait ce que tu nous expliques,
c'est que c'est pas une application avec une webview
qui va afficher ton application,
c'est un système qui installe,
comme si on cliquait sur le bouton pour installer.
C'est Edge qui est utilisé derrière,
donc...
Ah ouais, ça est complètement différent en fait,
donc ça marche beaucoup mieux,
c'est pas une webview.
Le prix de review,
ah ouais, si j'ai aimé taper de vouloir à fonction
dans Edge,
quasiment une copie à l'identique de Chrome,
mais je vous invite quand même à...
à pas que tester d'en gros,
mais tester d'autres navigateurs,
mais si ça marche,
et que quand tu l'installes depuis Edge,
ça marche,
tu auras exactement la même expérience.
On te génère juste un ID qui est différent,
parce que nous ça nous permet de traquer
que ça vient du store,
et du coup de te proposer, voilà,
dans...
elle est un peu plus intégrée
dans le système d'exploitation,
potentiellement,
mais quasiment pas différent.
Et par contre,
on a fait un autre truc dans cette technologie là,
c'est si tu lances le Task Manager sur Windows,
par exemple,
tu as l'impression de le voir comme une app,
mais en fait,
c'est juste un petit proxy qu'on a registré,
qui se comporte comme une app native,
mais derrière, c'est bien navigateur qui tourne, quoi.
Donc on a essayé vraiment de...
de pas créer un truc séparé,
comme tu disais, une webview.
Il y a beaucoup de gens qui pensent que c'est une webview.
Ouais, ouais.
C'est pas du tout le cas.
Sur Android,
sur Android,
il y avait plusieurs manières de le gérer.
Il s'est basé sur la dernière version de Chrome aussi,
et...
Je me souviens plus,
j'ai beaucoup travaillé avec eux pourtant.
Ils utilisent une techno
qu'on a embarquée, en fait,
qui est Open Source chez eux,
qu'on a embarquée sur PW Builder.
Et en fait, on est leur producteur numéro 1 de PW A pour Android.
C'est PW Builder.
Sur ça, qu'on avait des superbe relations.
Ils avaient une techno un peu différente,
mais c'est le même principe.
Et ils ont l'espèce de label
où c'est des trust web app, un truc comme ça.
Ouais, trust web app, voilà.
TW A, effectivement.
Et alors ça, c'est pas con,
c'est que...
Pour pouvoir utiliser, en fait,
l'app native, si tu veux,
native.
Je me mélange du coup.
Enfin, l'app installée,
la PW A installée,
et prouver que tu es bien le honneur de cette app
quand tu vas le publier sur le store.
Parce que là, imaginons...
Je ne donne pas de mauvaises idées au hacker,
mais imaginons que...
Je own babylonjs.com qui est une PW A, par exemple.
Et je me dis que je peux la publier dans le store Microsoft.
Je vais sur PW A Builder,
je rentre l'URL, ça me génère un package.
Je me crée un compte developer,
je me dis, voilà, je passe les validations.
Et je peux potentiellement publier l'app babylon sous mon nom.
Et éventuellement...
Alors que c'est à moi qui l'ajère.
Voilà, exactement.
Il se trouve que pendant la phase de validation,
justement, les humains qui valident ça
vont aller vérifier un minimum de choses
pour que tu...
Mais imaginez que tu pourrais passer à travers les mailles du FIAS,
ça reste humain.
Google a une approche que je trouve intéressante.
Ils te disent, OK, tu génères un APK
avec PW A Builder ou leur propre outil
pour gérer des...
Ça s'appelle bubble wrap, leur outil,
pour générer des TWA.
Et une fois que tu as ce package-là,
on va générer une espèce de clé,
de signature de ce package
que tu vas mettre à la racine de ton site web
pour que ça matche les deux.
Et là, dans ces cas-là, si ça matche,
quand on exécute l'application PW A installer sur ton Android,
elle a vraiment le comportement de l'application native,
sinon tu as un bandeau en haut.
Et là, à cause de...
Alors c'est super comme idée,
mais à cause de ça, on a eu 12 milliards d'issues de gens
qui ne comprenaient pas comment ça fonctionnait,
qui disaient que soit qu'ils mettaient le fichier
au mauvais endroit,
soit qu'ils n'étaient pas honneurs vraiment, tu sais,
de l'hébergeur,
c'est-à-dire qu'ils n'avaient pas accès à la racine du serveur,
en fait, et ils avaient le bandeau.
Et donc voilà.
Mais l'idée n'est pas con, parce que du coup,
t'es obligé d'en...
Tu vas être con.
D'avoir les deux parties, quoi.
D'être à la fois de gérer ton code
et de gérer ton...
L'hébergement et de la publication...
Et de la publication...
Et nous, on aide sur PWA Builder à toutes ces étapes-là.
Ça congénère toutes ces étapes intermédiaires
avec de la doc.
Mais il y a toujours le moment où,
si tu ne suis pas bien la doc,
tu fais une petite sortie de route
et mes premiers réflexes des gens,
c'est de nous insulter sur une issue.
Au lieu de lire la doc.
Voilà.
Pour le coup, on a vu que sur PWA...
Sur PWA Builder, sur le site, justement,
au moment où tu soumets en fait ton URL,
il y a une phase d'analyse.
Si c'est bon, tu peux lancer le builder.
Et après, il y a toute cette phase de publication
sur les stores où là, c'est à l'utilisateur de le faire.
Par contre, vous avez écrit de la doc
pour justement faciliter la vie
et pour, on va dire, fluidifier un peu ce process.
Exactement.
Donc c'est peut-être plus facile sur Windows
et sur Google, sur le Play Store.
Par contre, sur iOS, c'est un peu solide quand même, non ?
Alors, sur iOS, on avait un builder.
Alors, quand j'ai repris le projet,
moi, je venais de Babylon,
donc j'avais une bonne culture de projet open source.
Il y a plein de trucs qui n'y avait pas dans le projet PWA Builder.
Donc, j'ai imposé une review des issues corrects,
de plein de trucs, de revoir le...
On avait une dette technique monstrueuse
et qu'on avait travaillé avec plein de prestataires
aussi avant de...
Le projet n'était pas entièrement géré par Microsoft
et c'est le problème classique
de d'avoir différents consultants qui se font de chacun
avec leurs propres tactiques, leurs propres visions.
Donc, on avait complètement perdu le contrôle des trucs.
Donc, on a reparti de zéro.
Et moi, je suis un gros fan des webcomponents.
C'est-à-dire que...
Et donc, je suis dit, on va partir sur du pure webcomponent
avec l'Eat Element par-dessus.
Donc, on a fait un refactor complet de notre front,
de notre backend aussi.
On est partait sur du serverless.
On en a profité pour se faire plaisir aussi
parce que l'équipe de devs que je connais,
les devs, on a besoin de leur faire faire des trucs sympas.
Mais un peu repos.
C'est-à-dire que, en fait, comme on avait une dette technique,
j'ai réussi à convaincre le management
qu'on allait dans le mur si on continuait comme ça.
Et iOS était une grosse verru.
C'est-à-dire que je pense que ça marchait quasiment jamais.
Vous ne voyez pas l'intérêt de le garder.
Donc, je l'ai dégagé.
Et c'était intéressant en le dégagant.
On a eu tous les mois des demandes genre,
il est où iOS, j'ai besoin d'IOS,
j'ai vraiment besoin de publier sur iOS.
Il ne se trouve qu'il ne marchait pas.
Je ne comprends pas pourquoi les gens...
Mais c'est une traction, c'est bien.
Il y a une demande.
Oui, donc il y avait une vraie demande.
Alors, c'est difficile d'évaluer quand même
parce que les râleurs, voilà,
on s'est prévenus que les gens qui sont contents.
Et du coup, on s'est dit, bon,
quand on arrive à avoir la réponse d'Apple,
c'est-à-dire, c'est supporté ou pas,
il y a quelqu'un de la communauté qui était en rue,
s'il me semble, qui dit,
moi, j'ai mis au point un template sur mon Mac.
Il semble passer.
J'ai déjà publié plusieurs apps dans le store
et là, ça va être le côté magnifique de l'OpenSword.
C'est-à-dire que le mec, il dit,
« PWA BitleHur, je kiffe parce que
vous m'avez fait gagner plein de temps,
je vous propose mon template. »
Et alors là, franchement, ce jour,
enfin, tant en tant, en tant,
des voix, tu dis, c'est magique, là, l'Open...
Souvent, ce n'est pas ça.
Les gens doivent savoir, souvent,
ils se tranchent à la gueule, putain.
Et donc là, le mec, il dit, ok,
donc on fait une revue de son truc,
ça a l'air bien, et on l'a pas 4G
pour générer un projet, en fait,
que tu ouvres dans Xcode,
qui est tout préparé pour qu'ensuite,
tu builds pour iPhone.
Moi, j'aurais bien aimé faire la même chose
que pour Android et Windows.
Sauf que pour faire ça,
il faudrait que j'ai un Mac dans le cloud
pour pouvoir générer le projet.
Et alors là, les gens doivent le savoir.
C'est strictement interdit de prendre une image Mac OS
et de le faire tourner sur autre chose
que du hardware Apple.
Je vais les utiliser, tout ça, c'est...
Ah là, sinon, il y a plus d'emprison,
on retrouve ta famille, etc.
Bon, c'est un dégraf, il faut un dégraf aussi.
Sinon, il faut prendre du hardware Apple
que tu mets dans le cloud
et que tu vas piloter, etc.
Mais c'est un vrai calvaire à gérer, en fait.
Donc on s'est dit, on va tester d'abord comme ça,
et tu parles de traction, de voir si les gens...
Parce que ça coûte tellement cher, tu vois.
Et moi, mon projet Open Source,
sa raison d'être principale,
c'est d'inciter les gens d'aller vers Windows.
Bien sûr, on ouvre sur toutes les plateformes,
mais bien on est financé par Windows.
Donc ça veut dire que si ça nous coûte une fortune en cloud
pour aider Apple qui ne fait aucun effort,
le management, il n'allait pas être d'accord, en fait.
Bien sûr, bien sûr.
Mais de toute façon, après, on n'en a pas parlé,
mais vous, chez Microsoft, vous avez un intérêt
à développer cet étudiant aussi.
Après, il faut être honnête,
et vous avez votre intérêt,
et les utilisateurs, on va dire,
les développeurs qui utilisent cet outil-là
ont aussi des intérêts à le faire,
parce que vous solutionnez beaucoup, beaucoup de choses.
Donc c'est un process où tout le monde gagne un peu
et tout le monde est content.
Pour moi, c'est la bonne façon de travailler avec les développeurs.
Mais j'ai dû lutter des fois,
parce qu'on a des marquetteux qui se pantaient en disant,
ils voulaient que ça clignote, tu vois,
que ce soit que Windows Azure sur la landing page de PwLabida.
Je fais ça, on s'est terminé.
Moi, je ferme boutique parce que tout le monde va se barrer.
Et donc, dans notre télémétrie,
on voyait que Android de l'où est le premier,
mais à chaque fois qu'il y avait une conf…
On travaille beaucoup avec les gens de Google,
donc on était fiturés dans la Google Iow.
Ça nous est venu vachement de trafic.
Et en fait, les gens, découverts à bâtiens,
je peux aussi pousser mon app dans Windows
pour super facilement et d'autres plateformes.
Donc c'était du win-win,
c'est-à-dire que nous,
bénéficiaient de l'aspiration quelque part de la plateforme Android.
Donc heureusement, les managers étaient suffisamment malins
pour comprendre ça comme tu disais.
Et les développeurs, c'est du win-win.
C'est que rien ne les oblige à pousser sur la plateforme Windows.
Mais par contre, on a pas mal de testimonials de…
Moi, je te dis, je travaillais.
Donc non seulement je travaillais le projet,
mais je travaillais avec des partenaires,
je travaillais avec Twitter, Pinterest, Adobe, Autodesk.
Oui, des petites boîtes quoi.
Oui, non mais je veux dire, c'est super intéressant.
On est problématiques,
je me dis si eux valident PWA,
je veux plus entendre le petit mec dans la conche qui dit,
« C'est pourri parce que j'avais un strip machin. »
Non, on va dire, regarde,
c'est peut-être que tu n'as pas encore les compétences pour faire ça,
mais regarde, ça marche quoi.
Eux, eux, aider aussi à tirer d'autres partenaires
comme tu disais le phénomène du moton,
c'est une fois qu'il y en a qui a issu des plateformes
et que les autres disent que vraiment ça marche,
on va peut-être essayer aussi.
Donc pour revenir sur le cadeau que t'as fait
à un développeur russe sur son template,
vous l'avez implémenté,
et maintenant, vous avez documenté tout le process
et en fait, vous buildez ce projet-là
et après, c'est à l'utilisateur,
alors non, au développeur de terminer le build
pour qu'il soit, on va dire, Apple Proof
et potentiellement validable sur le store.
Entièrement.
Ok.
Tu parlais de telemétrie, justement.
Je voulais savoir, est-ce que vous avez inséré quelque chose
dans les packages pour avoir des chiffres sur...
Oh là, malheureusement, surtout pas.
Surtout pas.
Mais vous avez des chiffres sur...
Oui, on a les chiffres au niveau de notre store
que je ne peux pas partager,
et puis en plus, je les ai pu accéder
au ce que j'ai switché il y a un an d'organisation,
donc dans celle-là, en cloison.
En termes d'ordre d'idées,
je ne sais plus combien on avait,
non, mais je ne crois pas que je peux donner ces chiffres,
mais du coup, on communique vraiment
sur les gros qui sont là, en fait.
Ok.
C'est pas aussi populaire que les gens
peuvent le penser aujourd'hui.
Il reste beaucoup de marges de manœuvre
pour rendre ça plus populaire,
mais je ne veux pas non plus, pour moi,
c'est que j'ai jamais été partisan
de que des web apps dans les stores, en fait.
Oui, je ne veux pas non plus
un trust web app partout.
Non, voilà, c'est que, comme tu le disais, Alex,
c'est aujourd'hui, il y a plein de choses
qui pourraient être faits en web app, en PWA.
Ça coûterait moins cher, plus simple à maintenir, etc.
Mais il y a plein de choses qui doivent être continuées,
il faut toujours le faire en natif.
Donc, ce n'est pas une guerre,
c'est sûr.
Chaque problème à sa solution.
Et les PWA apportent...
C'est un outil, c'est un outil
qui est plus ou moins adapté dans certaines situations,
mais ce n'est pas l'outil magique qui fait tout ça
et qui apprend à tout.
Mais en fait, ce que je vois,
surtout, c'est que ça peut amener
une solution simple, pragmatique
et hyper souple pour les développeurs.
Après, est-ce que c'est adapté à tout ?
Non, et clairement.
Oui, oui.
Et puis les développeurs, ils doivent savoir.
Quand on te vend le truc magique de la solution à tout,
c'est qu'il y a un gros sarnac quelque part.
On l'a fait plusieurs fois dans l'histoire de l'informatique.
Mais même les marketeurs, ils le savent très bien.
Quand on produit, c'est pour tout le monde.
Au final, c'est que c'est pour personne.
Donc, même un marketeur, il comprend parfaitement ça.
Trop bien.
Si il y a des marketeurs que nous écoutons, on les aime aussi.
On ne peut pas juste les dire.
On les adore.
Parce que, eux, ils vendent ce que nous, on fait.
Et donc, en fait, on a un besoin, clairement.
Non, mais pas de guerre, clairement.
Juste pour revenir sur PWL Builder,
il y a en termes de staff.
Je ne sais pas si tu es habilité à communiquer là-dessus,
mais il y avait combien de personnes chez Microsoft
ou dans l'unité que tu dirigeais,
ou sur le projet, il y avait combien de personnes
qui étaient dédiées à ça
et combien de personnes qui venaient de la communauté.
Donc, c'était plutôt des développeurs open source.
Quand je parle, tu citais tout à l'heure le développeur russe.
Carre-joint, l'équipe d'ailleurs.
Ah, parfait.
Ouais, donc, c'est un truc, c'est un message que je donne aux gens aussi.
C'est participer au projet open source.
Des fois, vous pouvez le transformer.
C'est toujours bénéfique de participer à un projet open source.
Ce n'est pas secret parce que moi, je militais
pour que ce soit un vrai projet open source chez Microsoft,
pas qu'un projet open source qui soit top secret en disant,
c'est pas...
Donc, en fait, tu vas sur le GitHub, tu vois tous les contributeurs.
Il y avait, l'année dernière, j'avais
deux devs full-time chez Microsoft,
qu'on appelle FTE chez nous, full-time employee.
Donc, un seigneur dev qui était plutôt ultra bon,
qui avait utilisé PWL Builder avant pour faire sa propre habe
dans les stores qu'a kiffé, qu'a postulé et qu'on l'a embauché.
Et donc, il était très bon en full stack, comme on dit aujourd'hui.
Mais je ne me passe termes là, mais en gros, il avait été bon en back-end
et en front-end.
Un qui venait de chez...
Qui géré le projet Stencil, qui commence à Stencil.
Donc, très bon sur les web-componentes et qui venait d'une entreprise.
Merde, j'ai oublié le nom.
Enfin, en tout cas, il était plutôt front, celui.
Donc, lui, il s'occupait du redesign complet de PWL Builder.
Il a plein de PWL lui-même.
Donc, en fait, on était consommateurs nous-mêmes du projet,
ce qui est bien, c'est à dire que moi, j'étais PM dessus,
donc full-time aussi.
Je connais un peu dessus, mais je géré surtout le projet.
Et voilà, donc ça faisait trois développeurs full-time.
Ensuite, j'avais deux vendeurs,
donc un qui s'occupait du design,
une fille top qui est aujourd'hui chez un concurrent.
Et un autre qui était top aussi, un développeur dessus.
Et, temps en temps, on avait des stagiaires,
mais ça n'a jamais été très productif d'avoir les stagiaires.
C'était plutôt pour qui se formient, qui se amuse.
Donc, tu vois, au final, on était cinq à tourner à peu près dessus.
Donc, trois FTI et deux vendeurs.
Sachant qu'après, on avait le support des gens de Edge.
J'ai discuté beaucoup avec Edge parce que Edge nous faisait les API
dans Edge, le Packager, etc., qu'on allait utiliser dans le projet.
Donc, eux, c'est des full-time employees sur le projet Edge.
Et on avait beaucoup de réunions avec eux.
Donc, eux, ils nous aidaient.
Et ensuite, je travaillais pas mal de réunions avec les gens
qui faisaient bubble wrap chez Google.
Donc, eux, ils étaient au moins deux devs dessus,
full-time sur tout ce qui était Trusted Web App.
Donc, tu vois, en fait, tu commences à voir l'extension.
Le côté communautaire,
ça n'a pas aussi bien fonctionné que je l'espérais.
C'est-à-dire que Babylon.js, moi, je me souviens,
ça avait mis au moins deux ans avant qu'on commence à voir vraiment.
Au début, tu sais, tu as plutôt des gens qui vont répondre aux questions,
faire de la doc, etc.,
parce qu'ils se sentent pas capables d'écrire du code.
Avant d'avoir les vraies premiers contributions de code,
ça prend souvent du temps.
Et PW Builder, on a, bah, à part le fameux développeur rusque,
du coup, on a embauché.
On a eu très peu de vraies contributions de code,
plutôt des issues qui t'aient me levés par la communauté,
qui sont pratiques, parce qu'ils font les tests aussi avec nous pour nous.
Donc voilà, à peu près la taille du projet.
C'est pas mal, pas mal de monde quand même.
Toi, tu as rejoint le projet quand, en fait, tu as repris le projet?
Moi, je l'avais repris il y a 2, 3 ans.
Et parce que, ouais, j'étais toujours fan du Web
et que j'avais Babylon.js comme succès.
En fait, ils voulaient que je n'ai rien appris et pas de terme dessus.
Mais c'était quand même, ça, c'est aussi,
c'est à dire la tête des managers, c'est, oh, tu as été successful
sur un projet Open Source.
Oui, mais en fait, là, le scope est totalement différent.
Donc...
Tu fais copier-coller, c'est bon, continue, vas-y, tu fais pareil.
Je comprends pas.
OK.
Et aujourd'hui, c'est un projet qui est toujours maintenu,
qui est toujours en évolution.
C'est quoi la roadmap?
Ouais, il est toujours maintenu sur la roadmap.
Donc Justin Willis, avec qui je travaillais beaucoup,
donc il bossait sur Stencyl, etc.,
qui était un ancien évangéliste,
surtout ce qui était Web Component.
Il était toujours convaincu de l'importance d'aller là
où étaient les développeurs.
Donc du coup, à l'origine,
P.W. Builder, c'était fait vraiment plutôt pour pas 4G,
t'aider un petit peu à partir de zéro, mais plutôt pas 4G.
Et en fait, on s'est aperçu qu'il y a beaucoup de devs
en regardant nos scores, parce que du coup, on maintient nos scores.
Et puis, on voit la qualité,
quelque part, ça nous donne un index de qualité des apps.
Et bien, il s'est dit, il faut les aider à médiorer ça
en allant directement dans VS Code sous la forme d'une extension,
donc il est petit peu un truc qui s'appelle P.W.A Studio.
Donc l'idée, c'est de pouvoir t'aider à facilement faire ton manifeste,
ton service Worker,
enfin directement dans l'outil dev,
plutôt que de faire des spèces d'aller-retour
où tu vas sur le site P.W. Builder,
qu'on donne un morceau de manifeste à injecter ou des icônes, etc.
C'est une sorte d'assistant, en fait, c'est une sorte d'assistant.
De la complétion.
Ouais, il y a un...
Une extension, ouais.
Ouais, c'est une extension.
Il peut y avoir un peu d'autocompression,
par exemple des propriétés dans le manifeste,
ben...
Ben moi, moi, je...
Enfin, à chaque fois, j'ai l'ai sur l'aspect du W3C,
parce qu'il y en a, j'oubliais quoi, tu vois, les différents formats,
j'ai jamais trop compris, là, des...
L'unscape machin, etc.
Tu vois, enfin, ça, là, c'est assez simple,
il y en a des propriétés, bon, ben, du coup,
tu peux le faire sous la forme d'une extension
avec un petit peu d'infobules par-dessus.
Et donc, je sais pas, il faudrait que je discute avec eux
pour savoir à quel point ça fonctionne bien.
Donc moi, je travaillais avec des PMG Edge,
on a chipé un truc...
Alors, on reprend beaucoup de choses qui viennent de Chromium, bien sûr,
mais nous, on voulait...
On a nos propres contraintes.
On avait beaucoup de demandes, par exemple,
de customiser la...
La...
La tasque, enfin, la...
La barre en haut de...
De ton application.
Donc nous, on a créé un truc qui s'appelle Windows Control Overlay,
où tu peux justement faire comme électron,
une app Electron, en fait, tu peux...
faire ton appel, une window-est, et ensuite, c'est toi qui t'occupes
de mettre du HTML partout pour...
Pour designer ton look and feel complet de ta fenêtre.
Et donc, du coup, tu es obligé de refaire des boutons minimisés,
maximisés, etc., en HTML.
Donc ça, c'était une demande des gens qui voulaient porter
leurs app Electron, en fait, vers des PWAs,
parce que du coup, l'avantage, c'est que tu n'as pas besoin d'installer Electron,
tu es dans le navigateur, tu es potentiellement plus performant.
Et donc, et de pouvoir s'intégrer le plus possible dans le système,
et de remplacer...
Alors ça, ça va être arrivé par nos retours d'un partenaire,
de... on avait un partenaire qui disait,
moi, j'ai besoin, quand j'ouvre une fenêtre,
de le garder dans la fenêtre actuelle, et pas d'ouvrir
un deuxième fenêtre de navigateur.
Donc, typiquement, un client qui pourrait t'intéresser,
c'est Airbnb, par ça, tu vois.
Donc, souvent, ta façon d'utiliser l'app,
c'est que tu ouvres plein de trucs différents,
mais eux, ils voulaient le capturer dans un contenir principal, tu vois.
Donc, en fait, on évalue les demandes des partenaires,
on les... on donne des priorités,
coups en termes d'ingénierie,
on va voir avec d'autres partenaires si ça les intéresse,
et, ben, et ensuite, on les pousse dans la plateforme.
Donc, la roadmap, c'est très draïvé par des retours des... des bigs.
Mais maitre, quoi.
Ouais, bien.
Mais si jamais, ben, les vitidiaiseurs se manifestent aussi sur le repo,
ben, aussi, on regarde ça.
Si jamais on voit que ça fait 10 fois ce mois-ci
qu'on nous demande ce truc-là,
c'est qu'il y a un signe suffisamment important
pour qu'on s'intéresse à la question.
OK.
Et est-ce que tu connais les... les... les grosses features
ou les... les...
les... on va dire, les... les fonctionnalités qui vont sortir
sur le... le PDA...
le... sur le PDA builder?
Est-ce que ça va beaucoup bouger?
Ou en fait, aujourd'hui, on va dire, le socle est en place,
et c'est de l'amélioration d'essayer de réduire
toute... toute cette phase de... de friction, quoi.
Ouais, je pense que le socle est en place.
C'est pour ça, quand j'ai quitté l'équipe, moi, moi j'aime bien le...
la partie un peu pourrie du démarrage, c'est un peu bizarre, mais...
d'avoir la... la...
... un peu... voilà, c'est ça.
Mais le problème principal qu'on avait, c'était les discussions
autour de la qualité.
Et c'est une discussion que j'avais avec les gens de Google.
C'est au démarrage, on disait comment on...
on évite les crapp-apps et comment on filtre sur la qualité.
Donc au début, on s'était dit, eh ben, tiens, on va prendre Lighthouse,
on va prendre, c'était un score maximum.
Est-ce que ça veut dire que c'est une bonne app, tu vois.
Et... et du coup, on était voir avec les gens de Google
et eux, ils nous ont dit des souverainement intéressants,
c'est, ben, nous, on a fait le travail.
Du coup, on a regardé le score Lighthouse,
on a regardé les reviews dans le store des PWA
qui ont été générés avec... et ça ne match pas.
C'est pas parce que t'es un mégascore, en fait,
technique quelque part Lighthouse,
que ça va être apprécié par les utilisateurs.
Et inversement, c'est pas parce que t'as été...
t'as été un peu lazy sur l'implémentation de certains trucs
que tu vas pas voir une app qui fonctionne super bien.
Donc... et...
je vais pas citer les partenaires avec qui j'ai travaillé,
mais des fois, je trouvais qu'ils étaient pas très...
j'étais un peu déçu de l'effort qu'ils faisaient
sur l'intégration, parce que moi, je voulais aussi m'en servir
comme showcase, tu vois, pour me voir de haut de dire.
Et des fois, ils faisaient vraiment le ber minimum
et ils avaient des mégascores dans les...
dans les reviews, parce que c'est...
ce qu'il faut se rappeler, c'est que l'utilisateur,
c'est pas comme nous, c'est pas un dev,
ce qu'il compte, c'est...
s'il a sa feature de base qui...
qui lui permet de faire ce qu'il veut faire,
à limite le fait que ça soit top moumoud sur Service Worker,
surtout l'intégration de l'OS,
s'il n'en voit pas l'intérêt, comme les notifications
dont on parlait, hein.
Oui, il va être content, c'est...
et donc, il y a vraiment toujours cette dichotomie
entre le besoin utilisateur, est-ce que nous,
on aimerait bien...
La qualité intrasec du code technique,
qui nous nous importe, et la qualité de l'utilisateur,
où ben moi, ça répond mon besoin, basta quoi.
Oui, alors les deux sont quand même un peu corrélés,
mais pas autant qu'on le pense,
parce que forcément, s'il fait de la merde,
l'utilisateur, il va peut-être utiliser ton application,
mais...
Mais des fois, on pousse le cure sur trop loin dans la qualité,
en pensant que ça va forcément...
booster la tâche, etc.,
ou les rigiaux, mais c'est pas...
ça pas l'air d'être si évident que ça.
Donc, on n'a pas craqué ce...
ce problème-là, c'est comment définir
ce que c'est une PWL qualité,
et quelles sont les moyens ensuite de mesurer ça
de manière automatisée, quoi,
parce que nous, on a une plateforme pour automatiser,
donc je sais pas où ils en sont...
C'est quasiment impossible,
parce qu'il y a une notion d'ergodomie,
tout ça, du X, que tu peux pas automatiser.
On est parti loin dans nos délires, aujourd'hui,
t'as Open AI, t'as de l'IA Super Average,
t'as la DUA, donc on s'est dit,
ici, on entraîne...
on est parti loin, on n'a pas testé,
parce que ça coûte cher après,
d'entraîner un modèle, mais on s'est dit,
si on arriverait à avoir une IA qui nous donne,
tu vois genre, les best practices du UX,
comme tu le disais, parce que c'est beaucoup lié
à l'expérience utilisateur, donc...
mais ouais, on s'arrêtait là,
ça l'écoutait trop cher.
Mais en même temps, est-ce que...
est-ce que aussi, quand tu bosses sur des projets
comme ça, tu dois pas gérer, en fait,
le over-engineering,
à ma toute petite échelle,
je...
ce que je vois, parfois, c'est...
les devs, et moi le premier, parfois,
on est super content de faire un truc
méga complexe avec des techno, tout,
mais on perd le fil,
et en fait, on fait un truc complètement over-kill
et over-engineering, quoi.
Est-ce que toi,
alors là, c'est plus une question
sur ton boulot de PM, tu vois,
de gestion des devs et du projet,
est-ce que c'est un truc sur lequel
tu dois vraiment t'attarder ?
Moi, je suis un supportale, Alexa.
Je suis...
c'est-à-dire que...
pour moi, mon pire ennemi, c'est le...
l'espèce de...
de devs qui cherche la perfection
et qui va me défoncer mon projet, parce que...
et donc... et comme je...
je maîtrise encore suffisamment le code,
je peux moins être facilement
bullshitter, on va dire,
mais on l'a eu sur les projets open source,
Babylon ont eu des mecs qui ont voulu
dire, vous faites pas telle paterne de la mort, etc.
Mais moi, c'était super pragmatique, c'est...
ces performances, ça marche, les utilisateurs
arrivent à l'utiliser. Si tu me fais une API
aussi simple, avec toutes tes paternes
de ouf, qu'on vient de te faire plaisir,
vas-y. Le...
le repo, il est là, je te regarde faire.
Et souvent, ça stoppait le truc, quoi, tu vois.
Mais on a eu... on a eu des projets
où c'était vraiment problématique et...
et ce côté de...
euh...
c'est mieux que ça soit, c'est l'expression
it's better done, zahne perfect.
Bah moi, c'est vraiment mon credo.
Donc, bien sûr,
ça veut pas dire non plus que, tu vois,
on va faire de la merde.
Mais j'étais là gentiment, pour expliquer
des fois à mes devs,
qu'on va chipper, on va
regarder ce que ça donne, on va apprendre de ça.
Surtout que nous, on est... on a un site web,
donc on est dans un côté, tu vois,
de... de...
de... des livres...
continuous des livries, tu vois, je...
C'est des CIA, hein.
Et donc, du coup,
ça sert à rien de se...
on est pas comme un produit, comme Windows,
où là, tu as des Chines, tu vois,
tu as tout un ensemble de tests, et que si jamais
tu te loupes, tu te manges six mois
de fenêtres, etc.
Nous, on avait pas ces problèmes, à ce qu'il y ait, quand même,
à convaincre les développeurs de... t'inquiète pas,
parce que le problème de l'Open Source aussi, c'est
de la peur d'être jugé
sur la qualité de ton code, tu vois.
Donc, c'est pour ça que des fois, ça crée ce
phénomène de développeurs qui disent, non, non, il faut vraiment que ça soit
top, nickel, etc. et ensuite, tu vas y attendre.
Tu vois, ce projet Open Source, il est, ouais,
va voir la gueule du code source,
ça va te détendre, et tout se presse bien pour...
tu vois, c'est...
Donc, il faut savoir, quand même, se positionner
dans... dans... dans cet échelle-là.
Super, c'est... super intéressant,
et... et...
ça... ça ramène aussi, sur le fait que tu disais
tout à l'heure, justement, on a tous à gagner
à... à déjà aller lire
le code source et participer
à sa moindre... contribuer.
Contribuer, ouais, exactement. Pour être...
embauché chez les Microsoft, plus tard.
Je vous garantis peut-être, je le garantis pas forcément
que c'est embauché, mais moi, c'est...
Je coach les gens qui me demandent, c'est quoi,
le moyen d'être embauché, pas que chez Microsoft,
et dans les... dans les gars femmes,
si ça intéresse les gens, parce que ça intéresse pas forcément les gens,
je leur dis, ça aide vachement
les contributions au projet Open Source.
Alors, pas un petit commit, genre, j'ai modifié
une virgule dans la doc, tu vois, mais...
J'ai modifié une typo, quoi.
Ouais.
Ok.
Juste pour terminer,
on... il y a...
une conférence qui va sortir,
qui va... qui va avoir lieu le 5 octobre,
je crois, qui s'appelle
PWVA Summit.
Tu connais déjà le concept,
tu as déjà œuvré pour...
pour cette conférence?
Ouais, alors, on avait commencé, c'était la dernière,
je crois la première, il me semble, il y a 2 ans et un an,
mais en fait, on discutait Google des PWVA,
on a fini par se réunir, tous les acteurs,
parce qu'on avait tous les mêmes problèmes.
C'est pour ça que PWVA marchait bien, c'est Android,
ils avaient un problème de qualité, comment aussi
convertir ou influencer
les gens pour qu'ils connaissent ce truc-là,
pour que ça fasse partie de leur portfolio
des solutions possibles.
On s'est dit, comment, enfin, on arrête pas de parler
des... moi, j'ai l'impression, à chaque confre,
quand je dis qui connaît les PWVA,
j'ai l'impression que je soulais tout le monde depuis des années,
et à chaque fois, il y avait des gens qui en avaient pas la moindre idée
ce que c'était, ils ne savaient pas
ce que c'est un service pour coeur, etc.
Donc on s'est dit, bon, faut qu'on se mette tous
autour d'une table et qu'on fasse un event ensemble.
Et on s'est dit plutôt que de prendre nous-mêmes la parole,
plutôt le donner
à des gens de la communauté,
qui sera peut-être crédible et pertinent,
d'aller dire, moi, j'ai travaillé tel client,
j'ai fait une PWVA, voilà, les emmerdes que j'ai eues,
mais voilà, tous tous les côtés bénéfiques.
Bien sûr, avec une participation minimum,
parce qu'il y a des gens qui aiment bien voir
les officiels de Google, Microsoft parler,
parce que ça a une portée différente.
Ça a l'assurant, non mais bien sûr.
Même chose, mais...
Mais voilà, c'était le concept, et c'était vraiment
l'idée, c'est de dévangéliser,
tu vois, le concept de PWVA pour...
Moi, ce qui me frustrait, c'est quand je voyais des gens,
comme tu disais, Alex, qui est dans le store,
ils me disaient, mais c'est vraiment bête,
qu'ils n'aient pas pensé à faire une PWVA, franchement,
ça aurait été vraiment mieux pour eux, quoi.
Et donc, c'est pour éviter ça à l'avenir,
et puis nous, c'est l'intérêt, c'est qu'on utilise nos technos
et que ça nous aide à les faire développer, quoi.
Yes, donc c'est le 5 octobre,
c'est un événement qui est gratuit
et tout est streamé
en live.
Il y a
à la fois des retours d'expérience,
mais aussi des best practices en mode,
ok, on a solutionné
tel problème en faisant comme ça, comme ça, comme ça.
Et...
Ok, super.
Tu veux rajouter peut-être un mot
pour terminer un message
à passer une bouteille à la mer,
ou je sais pas, David ?
Non, j'espère que du coup, les gens ont compris
que c'est pas la solution magique à tout,
mais il faut vraiment la creuser un petit peu.
C'est fabriquer une application, donc c'est pas...
je vais pas être dénigrant sur des sites web,
mais c'est potentiellement plus complexe,
ça demande du coup plus de travail de polish,
plus de compréhension de la plateforme.
C'est un vrai problème qu'on a même chez Microsoft,
moi des jeunes qui ne maîtrise pas,
ils pensent que Virtualdom, par exemple,
c'est magique, donc qui se passe rien,
tu vois, donc il faut quand même
monter au fur et à mesure, mais c'est en faisant
aussi des erreurs qu'on apprend, donc tester
les PWA sur des projets, peut-être,
l'horizco, des maraches, si vous avez encore peur.
Mais regardez, il y a des acteurs incroyables.
Et moi aujourd'hui,
j'ai switché sur, tu vois, Teams,
c'est des web apps, et aujourd'hui,
pour publier des apps dans la plateforme Microsoft 365,
tu peux prendre les mêmes principes
que les PWA, les mêmes jeux de compétences
de comment optimiser ton app, etc.,
tu vas les utiliser. Donc, Microsoft,
on pousse, on est full throttle
sur web apps, donc
sous-estimé pas ça
pour votre propre carrière, si vous nous écoutez,
si vous n'êtes pas
encore un dev complètement
accompli sur le dev web,
je pense que c'est pas près de s'arrêter
de ralentir les web apps
dont les PWA, mais d'autres choses
qui sont à venir. Donc,
c'est pas un investissement
pourri
d'investir sur les techno-webs.
Oui, mais tu fais bien de dire ça,
parce qu'on a beaucoup de personnes en reconversion
qui nous écoutent, donc ça va les motiver aussi.
C'est bien, nickel.
Un grand merci.
Un grand merci, Patrick.
Un grand merci, David.
On remercie tous ceux qui sont restés
jusqu'au bout de l'épisode.
Trop bien.
Un grand merci à vous. Ciao, ciao. Merci David.
Ciao. Bye bye.
Retrouvez Double Slash
sur vos plateformes de podcasts préférés
et sur le site internet du podcast
www.slash-podcast.fr
Sur le site, vous allez retrouver tous les liens
de l'épisode, les références évoquées
durant l'émission.
Episode suivant:
Les infos glanées
DoubleSlashPodcast
Double Slash, un podcast sur le développement web. Retrouvez-nous régulièrement pour parler de sujets variés tels que la JAMStack, l’accessibilité, l’écoconception, React.js, Vue.js, Next.js, Nuxt.js, le CSS et des retours d’expériences sur des implémentations.
Tags
Card title
[{'term': 'Technology', 'label': None, 'scheme': None}, {'term': 'Technology', 'label': None, 'scheme': 'http://www.itunes.com/'}]
Go somewhere
SEO 2022 avec Dan Bernier