Bonjour à tous et bienvenue dans cet épisode, épisode particulier parce que pour la première
fois sur Double Slash, on va accueillir une développeuse féminine qui nous a rejoint
pour parler de PWA.
Bonjour Stéphanie.
Bonjour.
Et comme d'habitude, Patrick est avec nous.
Salut à tous.
Du coup Stéphanie, tu as écouté le show, tu nous envoyais un mail, on a discuté et
on a trouvé que c'était quand même hyper intéressant de t'inviter pour parler de PWA
parce que ça fait deux ans que tu travailles sur des PWA et donc ton retour d'expérience
serait un petit peu, enfin serait super intéressant.
Du coup avant d'embrayer directement, est-ce que tu peux te présenter un peu ton background
et tout ça ?
Oui bien sûr.
Donc je m'appelle Stéphanie, je suis développeuse web.
Je travaille actuellement à Amsterdam.
J'ai fait mes études en France et j'ai décidé de commencer mon premier travail au
Pays-Bas dans une entreprise qui s'appelle Ice Mobile et donc je m'occupe de la partie
web.
On fait des applications pour des supermarchés, des applications pour des programmes de fidélité.
Donc les utilisateurs peuvent collecter des teintes et voir sur l'application combien
teintes brisons, leurs transactions, ce qui peuvent recevoir gratuitement grâce à leurs
teintes ou les promotions du programme.
Donc oui et mon entreprise s'est concentrée sur les programmes et web app.
Toutes nos applications web sont maintenant basées que sur les progressives web app et
on commence à réduire aussi nos applications natives pour les remplacer par des web views
ou des applications web uniquement.
Et ça fait deux ans que je travaille dans cette compagnie et que je travaille assez
avec les progressives web app tous les jours.
Ok, super.
Du coup je pense que tu es super calé par rapport aux problématiques de safari donc
on va pouvoir en parler un peu plus tard.
Avec plaisir.
C'est un petit peu le vilain petit canard des progressives web app mais bon c'est comme
ça on reviendra plus tard dans l'épisode.
Donc pour commencer on peut définir ce qu'est une progressive web app ?
Et peut-être que pour le restant de l'application on pourra dire PWA.
Ouais, ça sera plus simple.
On gagnera du temps.
Et du coup c'est quoi une PWA progressive web app ?
Oui je pense que c'est bien de le définir parce que surtout pour les personnes non
techniques j'ai remarqué au travail on dit PWA et ils disent c'est quelque chose,
c'est pas une application web, c'est quelque chose de encore au dessus.
Donc juste pour être clair une progressive web app Speedway, c'est une application web
qui a un service worker donc c'est quelque chose qui est du côté client du navigateur
qui va pouvoir intercepter les requêtes du serveur avant qu'elles arrivent sur le navigateur.
Et grâce à ça on peut faire du cache, donc par exemple on peut cacher des assets, des images
et on peut les rendre directement.
Donc le navigateur va avoir ses assets, va pouvoir les rendre directement sans passer par le serveur.
Donc c'est pour ça qu'on peut avoir un mode hors-link par exemple.
Il peut faire beaucoup plus de choses comme des push notifications par exemple.
Et donc l'application web est plus facile car on peut rendre par exemple la moitié de la page
via le service worker et pas attendre la requête du serveur.
Donc ça c'est une partie importante des PWA.
Là-bas le terme de vitesse tu parles ?
Oui en termes de vitesse donc par exemple si on veut mettre en cache grâce au service worker
toutes les grosses images d'une page par exemple.
Donc il y a plusieurs stratégies pour un service worker, on peut choisir de prendre les assets dans le cache
s'ils existent avant que ça aille au serveur.
Du coup ça c'est directement rendu sur la page.
Donc toutes les images vont être instantanées et vont mettre très peu de millisecondes
à être rendu sur la page alors que si il devait y avoir une requête au serveur
on doit attendre la réponse pour pouvoir afficher l'image.
En fait le service worker il agit comme une sorte de proxy.
Il intersse toutes les requêtes.
Ensuite c'est toi qui choisis via le code que tu auras généré.
Si tu mets les choses en cache ou pas etc.
Chaque requête interseplée par le service worker c'est vraiment le principe proxy.
Exactement et après exactement on peut choisir ce qu'on peut faire avec.
On peut choisir d'ignorer service worker et de prendre toutes les requêtes depuis le serveur
ou de prendre le cache en premier ou le serveur en premier.
Il y a vraiment plein de stratégies possibles.
Et ça c'est ce qui permet de rendre le rendu de l'application plus rapide si on le fait intelligemment.
Il y a deux choses.
Le minimum pour être une PWA en fait c'est déjà bien le service worker comme je l'ai expliqué.
Et ensuite c'est le web manifest aussi qui permet en fait tout ce qui est icône etc.
Exactement donc le web manifest c'est un fichier JSON.
Donc dedans il y a le nom de l'application, quelques icônes qui sont obligatoires.
L'URL avec lequel l'application va être ouverte si on veut l'ouvrir en tant qu'application presque native.
Il y a la couleur de l'application donc il y a pas mal de choix.
Et ce fichier doit être présent et avoir au moins les icônes pour que l'application web soit reconnue comme progressive web apps.
Il n'y a pas besoin que le fichier fasse quelque chose en soi, on ne pourrait rien faire avec.
Mais la partie bien c'est que les PWA on veut se rapprocher de l'expérience native.
Donc par exemple si je vais sur une application web PWA je peux sur mon téléphone télécharger l'application en tant que...
En tant qu'application native donc ça va mettre un raccourci de mon application web parmi mes applications mobiles.
Il n'y aura que le shell donc une petite partie de l'application qui sera installée donc ça prend pas de place.
Et quand je clique dessus j'ai ma page web qui s'ouvre.
Donc le manifest permet de faire ça de se rapprocher de l'expérience native.
Donc les minimums pour être PWA quand on veut transformer.
D'ailleurs j'ai une question à ce niveau là.
Est-ce que vous considérez qu'une PWA ne peut être qu'une web app ou un site internet peut être aussi une PWA ?
Quel est votre avis là dessus ?
Je suis pas sûr que ça répète la question mais n'importe quelle application web peut être une PWA c'est un service worker installé mais qui ne fait rien par exemple.
Un manifest avec les propriétés qu'il faut et qui ne fait rien et quelle ce soit une application HTTPS secure.
Donc toute application web peut avoir ça c'est par défaut, par définition une PWA mais ça va rien apporter.
La question c'est est-ce qu'une PWA c'est pas forcément une web app en fait c'est ça que je veux dire.
Est-ce qu'un site internet dès qu'on lui rajoute un service worker un web manifest et on met un HTTPS ça devient une PWA ?
Ou est-ce que ça peut pas l'être parce que c'est pas une web app ?
On part définition salée après moi je dirais que salée parce que toutes les PWA peuvent avoir des tonnes de scénarios possibles donc ça dépend ce qu'on a besoin de faire avec.
Mais si on se colle à la définition toute application web peut être une PWA c'est pour ça que dire mon application web est une PWA ça veut un peu tout et rien dire.
Tu as l'ex ?
Moi je t'avoue c'est un peu de la sémantique.
Moi je pense que si on se rapproche de l'expérience native en mode, moi je parle toujours de ma mère qui ne connaît pas trop à la tech.
J'ai dit que tu installes ça et elle clique sur installer BIM c'est install et que ça soit une PWA ou l'Apple Store on s'en fout un peu.
Quand tu montres une PWA qui est bien faite ou sur un iPhone il faut l'installer soi-même, c'est un autre sujet mais quand tu cliques dessus BIM tu as un espèce de splash screen avec le logo ça charge.
Après t'arrives tu as une navigation fluide, le badot moyen c'est pas péjoratif mais quelqu'un qui n'a pas un œil averti sur la tech, lui il voit pas la différence, il sait pas du tout ce que c'est.
Et donc lui il est persuadé que c'est une app, c'est une app, en fait c'est une app.
Après trouver la sémantique juste, c'est un usage, c'est une vision un peu plus tech et moi je renais toujours ma maman, est-ce que ma maman elle installe et voit la différence ou pas ?
Si elle voit pas la différence c'est bon, c'est une app.
C'est clair qu'il y a des apps, enfin moi j'utilise beaucoup, principalement en PWA j'utilise l'application Twitter, puisque j'ai pas installé l'application Twitter j'utilise la PWA.
Et c'est honnêtement, je vois pas la différence en fait, elle marche tellement bien, c'est tellement léger que...
Ah c'est sûr.
Tu vois pas la différence entre une application native et la PWA Twitter en fait.
Et c'est vrai que, enfin ce qu'il me manque, à mon avis, mais ils sont en train de l'implementer, peut-être que tu as confirmé ça, mais de pouvoir installer les PWA.
D'ailleurs c'est ce que vous faites, c'est ce que tu nous avais dit, d'installer depuis le store une PWA sur ton Android, c'est ça ?
Ah ouais c'est ça, donc il y a plusieurs...
C'est possible aujourd'hui.
C'est possible avec quelques conditions et plusieurs possibilités.
Sur le Google Store c'est un peu plus simple.
Il y a les TWA, Trusted Web Apps, qui existent maintenant.
Donc c'est rajouter un shell autour de l'application Web Lab Tool PWA pour qu'elle soit...
Pour qu'on puisse la mettre sur le Google Store.
C'est plus pour les personnes...
Pour les développeurs qui ne sont pas développeurs d'applications natives, donc ils ont juste besoin de développer leur application Web,
de la mettre dans un shell, ils n'ont rien à faire et ensuite ils peuvent la mettre dans le Google Store.
Un shell c'est quoi ? C'est une WebView ?
Donc il y a le shell pour les PWA, le shell c'est le squelette de la Progressive Web App.
Quand je parle du shell natif, donc c'est là où la Progressive Web App va habiter dans la structure native, donc la coque native.
On ne peut pas mettre une application Web directement, même dans le Google Store, sans shell natif autour.
Ok.
Vous pouvez mettre de view de shell pour l'Apple, où tu peux injecter ta view directement.
Et tu as juste à faire tes modifications et ta shell qui est out of the box.
Tu viens le config avec tout ce que tu veux, qui vient charger ta view.
Et ta view c'est ta PWA qui est distribuée sur le Web.
Ça existe, c'est possible, ça marche, c'est Apple valide.
Alors je dirais oui.
Donc il y a un exemple pas mal qui est PWA Builder.
On peut faire un build pour l'Apple Store, pour le Google Store et d'autres stores.
Donc il couvre un peu de tout.
De ce que c'est accepté par Apple, parce qu'en fait c'est assez simple.
Donc imaginons, on développe un site Web, on a un URL.
On utilise cette URL et on l'a fourni aussi de PWA Builder.
Et il va construire le shell autour.
Donc il va sortir un build.
Je crois qu'il faut toujours quand même le tourner sur sa machine.
Donc si on veut mettre quelque chose dans l'Apple Store, je crois qu'il faut un Mac.
C'est peut-être le point négatif, c'est à vérifier.
Mais en gros, le build est là, il n'y a pas besoin de développement.
Il y a juste besoin de le run et de le proposer à l'Apple Store.
Ou Google Store.
D'accord.
Et tu ne passes même pas par la case Xcode, tu n'as même pas besoin d'ouvrir Xcode et de faire des modifs.
Donc il y a le build, il y a juste besoin de le run et de le submit.
Après, je n'ai pas fait de tasse là-dessus, mais je sais que Apple accepte ce genre de build.
Parce que du coup, le point négatif, je n'ai jamais utilisé, mais c'est comme ça que je le vois,
c'est que si l'URL aussi, on fait un changement dans l'application Web, il faut refaire ce système.
Il faut refaire via le site Web, PWA Builder.
Il faut refaire l'application Web qui va contenir le nouveau build avec les changements et resoumettre à l'App Store.
C'est si tu changes URL ça ?
Non, si tu changes le contenu parce qu'en fait, je crois que à partir de l'URL, ils vont construire l'application native autour.
Ah oui, donc tu peux pas...
Oui, mais c'est comme ça que je le vois. Alors que par exemple, pour Android, les TWA,
il y a le shell autour et l'application Web vit dans la TWA, donc il y a besoin de déployer et pas besoin de resoumettre à l'App Store.
Non, ça c'est pour Google Store.
Ok, c'est quand même contraignant de devoir resoumettre.
Mais c'est comme une application native, parce que c'est un build native et pas un build Web.
Après, un des gros avantages aussi d'une PWA, c'est justement de contrôler son déploiement et sa distribution.
C'est-à-dire, j'ai un bug, je corrige mon bug, là je dois soumettre mon appli à Apple qui prend le temps qu'il veut pour la valider ou pas.
Et après, déployer la version, à savoir que peut-être j'ai des utilisateurs qui sont bloqués et qui vont peut-être désinstaller mon application,
parce qu'elle est bugue et tout ça, que le contrôle d'une PWA, enfin moi le gros avantage que je vois, c'est ça,
c'est on contrôle le déploiement et la distribution de son application.
Et ça, c'est juste monstrueux.
Parce que je vois que j'ai un problème, je peux le résoudre, je le déploie,
et on va dire c'est transparent pour le user, où je lui mets une petite notification en mode refresh ou pas.
Et ça c'est quand même plutôt sympa quoi.
Si je suis obligé de repasser à chaque fois par le builder pour refaire un build et resoumettre à Apple, je perds tout.
Tu perds tout, mais une bonne partie.
Oui, tu perds l'intérêt de la PWA et en plus, vu que c'est une app, tu risques de te faire taper dessus,
si jamais tu mets un store dedans ou un truc comme ça, on revient là-dessus après.
Après, c'est pas que des avantages, on va dire.
On a toujours un seul URL, du coup on a l'application qui peut marcher sur le web, sur Android et sur iOS.
On n'a besoin que d'un...
L'intérêt c'est pour le développement, c'est que tu fais qu'un seul code et tu parles en seul sur l'histoire.
Donc il y a quand même des avantages, mais oui je suis d'accord sur la partie où il faut redéployer, c'est pas l'idéal.
Mais il y a quand même d'autres façons, donc par exemple, mon entreprise est en train de travailler sur une solution pour pouvoir...
On livre des web-views qu'on intègre aux applications natives existantes des supermarchés,
pour ne pas avoir d'applications séparées dans l'app Store juste pour un problème de fidélité.
Et ce qu'on va faire pour un prochain programme, c'est de mettre notre application web dans notre propre chaîne natif.
Donc pour ça on a des développeurs natifs qui vont faire la coque natif qui va aussi gérer les push notifications et ouvrir notre web-view.
Donc la web-view on aura juste besoin de la déployer, on n'aura pas besoin de soumettre à l'app Store à chaque fois.
Et du coup c'est nous qui construisons manuellement la coque native autour.
Oui, d'accord. Vous faites l'application web-view et après vous gerez ce que vous mettez dedans.
Voilà, mais il faut des développeurs natifs aussi.
Oui, mais les développeurs natifs ne font que...
Le browser en fait, c'est un peu réducteur de dire que, mais ils font tout l'enveloppe, tout le squelette
qui vous permet en fait d'aller récupérer toutes les APIs natives, les notifications qui sont bloquées sur le web, chez Apple.
Aller récupérer le processeur s'il y a besoin ou des choses qui ne sont pas accessibles aujourd'hui via des APIs web.
Oui, exactement.
Oui, par exemple les push notifications.
Mais une seule chose pour Apple qui est bon à savoir pour ce genre de solution, c'est qu'on peut mettre une application native iOS avec le web qu'on veut dedans.
Mais l'application native a besoin d'un minimum de code natif pour que l'Apple Store l'accepte.
Donc il faut que l'application soit toute construite avec la web view et le code natif.
Et quand on soumet l'Apple Store, ces surprises, ça passe ou ça casse.
Mais il peut y avoir par exemple un onboarding, quelque chose autour qui fait qu'il y a cette code native pour que Apple l'accepte, mais c'est pas sûr.
Ils sont un peu picky ?
Oui, pas mal.
Ok, sans surprise.
Du coup, on peut enchaîner.
Donc si demain on a un client et on veut lui proposer une PWA, quels sont les arguments par rapport à une app native qu'on peut sortir ?
Nous déjà, on insiste sur la vitesse parce que quand on parle d'une application web, les gens pensent, ah, ça va sauter partout sur la page, ça va être super lent, ça va être blanc.
Donc on insiste sur le fait que grâce au service Worker, c'est assez rapide.
Que si le client veut se servir de l'application web en tant que PWA avec l'icône raccourci sur l'écran d'accueil, que c'est bien plus petit qu'une application native,
Une application native iOS, c'est au moins 20 MB.
Le shell d'une PWA peut être 2, 3.
Je crois que pour nous, on en fait à 10 maximum, 10 kilobytes.
Donc c'est assez petit.
Après, ça dépend aussi du développement, si on développe pas bien ou qu'on met tout en cache, bien sûr, ça va exploser au bout d'un moment.
Mais l'installation de base, c'est vraiment assez léger.
Après, le fait que ce soit multiplaform, on a besoin que d'un développeur web, au lieu d'un développeur web, un développeur iOS, un développeur Android.
Donc aussi pour les alignements, le design, c'est beaucoup moins de travail.
C'est moins cher à développer.
Oui, c'est sûr.
Maintenant, dans mon équipe, on n'est que des développeurs web.
Donc ça va beaucoup plus vite.
Il y a beaucoup moins d'alignements sur l'API, le design.
C'est beaucoup plus focus sur le web.
Elle est aussi indexée par Google, donc on peut la trouver dans la barre de recherche de Google.
Puis maintenant, on a quand même...
On pense à une application native, une application web.
L'application web peut rien faire de ce que l'application native fait, mais on a quand même des API natifs.
On a le Web Share API, l'accès à la caméra.
On utilise le barcode scanner, par exemple, pour scanner la carte de fidèle d'un client, pour pas qu'il ait attaqué le code.
On fait ça de la WebView, qui est dans l'application native, donc c'est possible.
Il y a aussi le projet Fugu, qui est basé pour avoir de plus en plus de fonctionnalités natives sur le web.
Ça, c'est pas exactement le projet Fugu, en fait ?
En gros, c'est un projet Chromium, et leur but, c'est de réduire le trou entre le web et les applications natives.
Il développe, mais du coup, c'est basé Chromium, il développe des fonctionnalités, par exemple, accès au fichier du téléphone portable,
toutes les fonctionnalités natives qu'on n'a pas encore dans le web.
D'accord, mais ça va être intégré dans Chrome, les WebView, dans Chrome, ou ça va être quoi ?
Ou un shell, comme tu dis ?
Pour l'instant, c'est des flags dans Chrome, parce qu'ils sont en phase de développement.
Mais par exemple, le web share API, il est déjà accessible.
Par exemple, le badge API, c'est avoir une notification combien de messages par exemple on a reçu sur l'icône de la PWA,
avoir un petit 1 rouge, ça, c'est déjà accessible.
Donc, il y a plusieurs phases, test, trial, jusqu'à la phase, c'est live, et vous pouvez l'utiliser sur ces versions de Chrome, par exemple.
D'accord.
Donc, ils travaillent vraiment dessus pour apporter toutes ces fonctionnalités.
Après, Apple ne fait pas partie de ce projet.
Non, c'est étonnant.
Donc, on aura toujours ce trou, mais après ce qui n'est pas faisable sur Apple, par exemple, push notifications, ou d'autres choses,
il y a toujours une autre façon de faire, je ne dis pas que c'est la meilleure ou la plus simple, mais il y a toujours SMS notifications,
ou passer par une intégration, si on est dans une application native, passer par l'application native, pour gérer les push notifications, par exemple.
Donc, il y a des solutions, c'est pas le plus facile, mais c'est bien que ce projet se focus dessus et que oui, ça fait avancer le web et se rapprocher du native.
Ok.
Pour répondre à la question initiale, qui est une PWA par rapport à une application native, c'est pas non plus obligé d'être en concurrence,
parce que beaucoup de grandes marques utilisent la PWA pour avoir plus de téléchargement native, parce que la PWA, il n'y a pas besoin de l'installer forcément.
Donc, ce sera plus rapide.
L'utilisateur va être content, il va rester dessus, et après avoir expérimenté l'application web, il va se dire,
« Ah d'accord, j'ai envie de la garder, je vais télécharger l'application native. »
Donc, ce n'est pas forcément en concurrence, ça peut être les deux en même temps, ça dépend vraiment de l'objectif.
Ouais, tu veux dire, je prends l'exemple de Twitter, offrir une expérience intéressante sur la PWA,
ça va peut-être me motiver pour télécharger l'application et utiliser l'application, et ça va réimment changer, elles sont quasiment identiques.
Pour s'en garder la PWA.
Ouais, c'est clair, c'est surtout plus léger.
Moi, c'est pour ça que j'ai l'utilisé, c'est très léger.
Exactement.
Parce que tu parlais du poids, et c'est vrai qu'aujourd'hui, je ne sais pas si vous avez le problème,
mais moi, j'ai pas mal de problèmes au niveau de, même si aujourd'hui, on a des téléphones qui font 64GB ou même plus,
mais on a tellement de photos et de musique, etc.
Que, ouais, ça m'arrive régulièrement de devoir désinstaller des applications pour gagner un peu de passe.
Oui, c'est sûr.
Et encore, nous, on est en Europe, mais il y a des pays, par exemple, au Brésil, ils n'ont pas des téléphones à 64GB,
donc ils doivent faire avec 8, 16 maximum, et ils peuvent physiquement pas installer toutes les applications qu'ils veulent.
Donc, c'est pour ça que PWVA, ça peut être une solution pour couvrir plus de personnes et apporter une solution
au plus de personnes possibles et pas seulement au pays riche et au pays super développé.
Donc oui, moi, je pense que c'est un des bons points de si on ne peut pas télécharger l'application native
d'avoir une expérience similaire avec une PWVA qui tient que quelques kilobytes, par exemple.
Donc, tu travailles avec des pays comme le Brésil, tout ça, qui sont en développement et...
On travaille avec certains pays d'Asie.
Après, nous, on a commencé à intégrer des WebViews aux applications native existant du client,
sinon, l'utilisateur doit télécharger l'application du client, plus notre application de fidélité.
Donc, il a deux applications pour un même client sur son téléphone.
Donc, on a poussé au WebView.
Donc, déjà, ça fera moins de place sur leur téléphone.
Ils n'ont pas besoin de faire la démarche d'aller l'inserler à l'abstours.
Ça apparaît.
En gros, il y a un point d'entrée qui apparaît sur leur application existante.
Mais nous, on se concentre plus sur la vitesse.
Ce, du coup, même si ils ont de la place sur leur téléphone, ils n'ont pas une super bonne connexion.
Quand ils sont dans le magasin, ils ont de la faible 3G, par exemple.
Donc, on essaie vraiment de travailler avec les service workers et de délivrer le contenu le plus rapidement possible
pour ne pas quitter l'application en bas de sa pas-charge de bout de 10 secondes.
C'est vrai que tu parles de connexion.
Enfin, nous, en tout cas, toi, je ne sais pas Amsterdam, mais en France, on est bien fournis en giga pour les téléphones.
Mais il y a certains pays où ils sont... Enfin, ce n'est pas du tout le cas.
Je sais que le Canada, c'est un peu limite au niveau des forfaits.
Et oui, c'est important.
Si tu n'as pas un gros forfait mobile, tu ne vas pas passer ton temps à télécharger les applications mobiles.
Ça, c'est beau.
Oui, c'est ça.
Ça te prend de la connexion.
Donc, PWA, c'est quand même plus léger.
Oui, puis PWA, il y a aussi le mode carrément hors ligne.
Donc, imagine, la connexion est tellement faible.
Donc, on peut servir des fichiers du service worker quand il n'y a pas de connexion ou quand la connexion est super faible.
Et on a aussi le background sync qui permet de...
Si l'utilisateur fait une action d'envoyer quelque chose mais qui n'a pas assez d'internet pour pouvoir effectuer l'action,
elle sera faite quand internet...
Quand il y a une connexion suffisante.
Donc, ça offre pas mal de possibilités de ce point de vue.
Moi, j'ai une question sur le côté marketing.
Tu parlais tout à l'heure d'installer les apps ou ça.
Alors, j'avais lu que côté marketing, c'était vachement bien parce que...
Enfin, les PWA étaient intéressantes parce que, justement, ça limitait la friction de l'installation.
Parce que si je découvre une application, elle me renvoie vers l'app Store.
Je dois cliquer sur Get, je dois la télécharger, après je dois aller dans mon...
Enfin, ça met beaucoup d'étapes.
Et en fait, il y avait des taux de transformation qui étaient bien plus intéressants sur des PWA.
Parce que, justement, on vient fluidifier et on vient limiter cette friction d'action nécessaire à lui.
Et en fait, l'installation d'une appli est un vrai frein, quoi.
D'autant plus qu'on sait que le temps de conservation d'une appli aujourd'hui, elle diminue vachement, quoi.
Donc, pour toutes les raisons qu'on a évoquées tout à l'heure.
Du coup, est-ce que TWA, tu as un peu plus d'infos côté un peu plus market en jouant aussi sur le fait de limiter l'installation
et en fait de limiter la friction à l'installation.
Est-ce que c'est un argument que vous utilisez ?
Est-ce que vos clients sont sensibles à ça ou pas du tout ?
Donc oui, on utilise, je pense que ça répond à la question, mais par exemple, sur l'application web.
On utilise l'application web, donc vraiment l'application sur desktop.
On met le lien vers l'app Store pour pouvoir pousser, parce que le client veut toujours que l'utilisateur t'écharge son application native.
Parce que bon, il y a plus de contenu dedans, en dehors de la WebZoo.
Après, l'application web en elle-même, oui, elle est plus facile à installer, parce qu'on n'a pas besoin de cliquer, d'ouvrir l'app Store ou Google Store,
de cliquer sur télécharger et d'attendre plusieurs secondes selon la connexion que l'application se télécharge.
On a juste un plus pour ajouter à l'écran d'accueil et l'application web va se télécharger beaucoup plus rapidement,
vu que c'est vachement plus léger.
Oui, je pense que les applications natives, il y a beaucoup trop d'étapes.
Et aussi, on demande de télécharger une application native sans pouvoir tester l'application elle-même.
Par exemple, on dit, télécharge l'appli Starbucks, mais on ne sait pas ce qu'on va pouvoir faire avec, on ne sait pas tant qu'on n'a pas téléchargé.
Et du coup, l'application web, on a déjà du contenu, avant de le télécharger, on sait ce qu'on télécharge.
Moi, j'avais des chiffres de 2018, j'avais fait un article là-dessus.
Il y a 80% des applications qui sont plus utilisées après 72 heures en fait.
Elles sont téléchargées et après, tu as 80% des applications qui sont plus utilisées.
Oui, c'est sûr. Parce qu'en général, on l'utilise pour une utilisation, parce qu'on a besoin de l'application,
donc on a pas le choix, on la télécharge, mais en soi, après, on en a plus besoin.
Donc, c'est dommage d'avoir investi autant d'argent pour ne pas utiliser.
Pour une utilisation, oui.
Les marquetteux, ils doivent s'arracher les cheveux. Ça doit coûter un barat.
Donc, oui, ok.
Et qu'est-ce qui aujourd'hui est le gros problème des PwVR ?
Oui, qu'il quelaient la grosse limitation qui freine les PwVR.
Sans parler de safari ?
Oui, c'est une question.
Tu parles de feature, en fait.
Oui, exactement.
Qu'est-ce qui quelaient la feature killer qui pourrait faire basculer le monde des applis en mode
« Ok, maintenant, on fait du PwVR, on y va, tacker ».
Donc, sans parler de safari, donc, par exemple, ce qui existe déjà sur Chromium.
Je pense que ce serait de pouvoir mettre la PWA sans shell,
grâce à un URL, la mettre directement dans les deux stores.
Donc, comme ça, ça couvrirait tout internet, donc avec l'indexation Google
et toutes les recherches via le store.
Donc, ce serait qu'on pourrait tout faire avec des applications web
et on ne utiliserait plus de native, donc je pense qu'il y aurait plus d'impact,
tout type d'utilisateur, parce que, en soi, nous, il nous manque rien.
En tout cas, dans ce que mon travail aujourd'hui, il me manque rien,
à part safari, de nos côtés, il nous manque rien pour apporter ce qu'il faut à l'utilisateur.
Oui, oui, c'est...
Il y a assez de fonctionnalités natives, on a les services work-ups, les push notifications,
tout pour le mode online.
Donc, je pense que c'est vraiment le store.
Et donc, du coup, le problème, c'est la soumission au store via une simple URL.
Ça serait vachement plus facile.
Ouais, sans URL.
Ouais, dans l'idéal, un fichier de config avec ton URL, machin,
ta description et tout, tu balances ça et hop, tu as tapé WL et dans le store.
Ça serait l'idéal.
Bois.
Ça serait magique.
Bois.
Ça serait magique.
Et maintenant, parlons de safari.
On ne peut pas parler de PWA sans parler du problème de safari dans iOS.
On est d'accord?
Ouais.
Alors, attends, j'ai juste fait avant qu'on commence quand même à rajouter,
parce qu'il faut juste se souvenir, en fait, que Steve Jobs,
quand il a sorti le premier iPhone, il avait complètement poussé les applications HTML.
Et je suis passé, vous vous souvenez, en 2007, il n'y avait pas encore de store
et pas d'applications via un store et Apple était à fond, application web.
Et après, on ne sait pas...
Voilà.
Et après, on ne sait pas trop ce qui s'est passé.
S'il y a eu l'app store et les revenus de l'app store.
Et voilà.

Et là, c'est le drame.
Et là, c'est le drame.
Et donc, il faut dire quand même que les PWA ont été lancés par Google en 2015.
Et qu'en 2020, ça décolle toujours pas des masses à cause de safari.
Moi, je pense que ça décolle pas mal.
C'est freiné par safari.
Mais il y a beaucoup de plus en plus d'entreprises qui utilisent les PWA.
Je sais qu'à Amsterdam, tout le monde recherche des développeurs PWA.
Je ne sais pas si ils savent tout ce que c'est une PWA,
parce que c'est un peu un mot magique quand on dit PWA.
C'est la belle hype.
Donc, les gens savent ce que c'est.
Et ils cherchent à pousser vers les PWA.
Donc, je pense que ça décolle aussi, parce que je travaille avec tous les jours,
il y a pas mal de clients qui tournent vers les PWA
au lieu d'anciennes applications web ou d'applications natives.
Donc, dans mon environnement, je vois ça décoller.
Après, je ne sais pas comment c'est en France.
Mais je pense que non, ça décolle.
Et comme je disais, safari, oui, il n'y a pas toutes les features,
mais nous, ça ne nous empêche pas de gérer les push notifications de toute façon.
Donc, ça rend pas les choses faciles, mais ce n'est pas impossible.
Oui, les push notifications, quand tu veux les gérer via safari,
c'est un petit peu compliqué quand même.
Ça me peut l'enfer.
Oui, parce que le service worker ne supporte pas la push API.
Oui, il est obligé de passer par leur système natif.
Après, on revient sur ce qu'on disait tout à l'heure.
Tu es obligé de mettre un shell tout autour,
qui prend toutes les applits natives.
Tout le reste, c'est via la web view et tout ce que le natif.
Après, je vois, j'avais réussi,
j'ai fait un tout petit projet pendant le Covid en mode site project
sur une pdouleva justement.
J'avais réussi à mettre une notification.
En fait, si l'agent mobile était Apple ou iPad,
enfin iOS, et il utilisait via son navigateur,
donc c'est-à-dire si l'appli, il n'était pas installé.
Parce qu'en fait, quand on installe, dans l'URL,
on change l'URL, on met un standalone.
Ce qui fait que je venais vérifier l'agent
si dans l'URL, il y avait standalone ou pas.
Et si il n'y avait pas ça,
je lui mettais une petite notification interne à ma vue,
en disant, pour installer l'appli, tu fais ça, ça, ça.
C'est un hack, soit.
Mais en fait, le mec, il utilisait toujours,
enfin, s'il venait sur l'URL, via son téléphone,
via son iPhone, et qu'il n'avait pas installé.
Alors, il prenait une petite notification
ajoutée à la homepage.
Tu lui expliquais comment tu lui expliquais et cliquais là,
ajoutais à la queue et machin, tout ça.
Oui, en fait, j'avais mis, pour une meilleure expérience,
cliquer sur le logo avec « share »,
donc le cliquer avec la flèche qui monte.
Puis, le logo ajouté à l'accueil, tu vois, « BIM ».
Et en fait, ça prenait un quart de l'écran.
Du coup, il le voyait, quoi, il le voyait.
Et pour le coup, s'il le faisait,
après, quand il l'avait installé,
sur son home screen,
quand il clique dessus,
l'URL est chargé via le standalone,
et donc, il ne prend pas la notification dans la tête.
C'est un micro-ac, on est d'accord.
Oui, mais c'est principalement ça pour contrer
ce que Safari n'a pas.
Donc, il y a toujours des solutions sur le côté.
Ok, il faut le faire, spécialement pour Safari,
donc ça prend plus de temps, mais c'est faisable.
Oui.
On va lister un peu ce qui manque dans Safari, en fait.
Enfin, ce qui manque.
Ce qu'il faut contourner, en gros.
Donc, la notification, déjà,
la première chose, c'est possible,
mais via les notifications,
le système natif de Safari, enfin,
d'IOS, en fait.
Mais pas par le service worker.
C'est quand même beaucoup plus compliqué
que le système du service worker.
Ça, c'est un peu de bon, voilà,
pour l'instant.
Par contre, attends, juste pour...
J'ai une question.
Tu peux nous en dire un tout petit peu plus
sur le grabbing à Pierre,
il a ce que tu nous as parlé tout à l'heure.
Pour les pushes de notification.
Oui, en fait, si j'ai une...
En fait, si je fais une push
à l'intérieur de mon appli, ok,
j'ai mon téléphone fermé,
il n'y a rien qui va sortir, je suis d'accord.
Par contre, est-ce que je peux quand même
afficher quelque chose sur l'icône ou pas du tout ?
Donc là, on est dans le cas.
Il n'y a pas de chale natif,
c'est une PWA qui est sur l'écran d'accail.
Et qu'on est sur Chrome.
Quand on dit Chrome.
Ok, du coup...
Ça, c'est les notifs du browser, en fait.
On peut faire quand l'application est fermée.
Donc en gros, il y a deux APIs,
il y a la notification API
et la push API.
La notification API, c'est le fait
de montrer une pop-up.
Donc, voici, vous avez une notification.
Et la push API, c'est
d'écouter, de recevoir un push
et ça, ça va
trigger la push notification.
Et ça, c'est donc, c'est le service worker
qui écoute ça.
Et le service worker,
donc le navigateur va faire un lien
vers ce service worker.
Donc, en quoi c'est celui qui s'occupe des push.
Et l'application, c'est
les fermées.
Donc quand le service worker va se dire
ah, j'ai un push, il va se réveiller
et envoyer la notification.
Ouais, ça c'est le browser qui prend
un charge.
Tu gères les notifications de Chrome,
surtout en Android.
Si elles sont ouvertes,
ton service worker reçoit un push
et il en voit pas.
Et j'ai pas trop travaillé en soi avec
les notifications, surtout pour les faits
tout natifs. Mais pour moi,
il y a le message
qui pop à l'écran et pas que
le batch. Parce que le batch
déjà, c'est une API différente.
C'est le
badging API.
Donc, je crois que ça fait
un message pop-up
en haut de l'écran
et quand on clique dessus,
ça ouvre la page.
Ouais, ça te fait une notification
comme une application
qui soit fermée ou ouvert.
À partir du moment où tu l'autorises,
tu auras une notification.
J'ai découvert ça il y a pas longtemps,
mais notification API,
c'est en fait supporté par Apple
sur desktop. Donc,
si la personne est sur le site Web,
on peut envoyer des notifications.
C'est pas des push notifications
mais on peut envoyer
si la personne a
l'application Web ouverte.
Donc, c'est quelque chose.
Ouais, après...
Après, est-ce qu'elle est ouverte ?
Mais en fait, si elle est ouverte
en bas-grande, il apprend quand même,
ou pas ?
Par exemple, je bascule
sur une autre appli
qui...
Je l'ai gueule classique, Mim.
Oui, mais par contre, ça passera pas
par un push, donc par un service
push qui va trigger service
worker. Ça va passer par toi dans ton
code, tu te dis
si y a-t-elle action, je fais voir
une notification. Donc, c'est pas vraiment push
notification, c'est vraiment juste la partie
notification.
Donc, j'imagine
après une action,
ou par exemple, l'utilisateur change d'onglet,
tu fais... oh, je reviens sur la page.
Là, par exemple,
il faut qu'il y ait une action d'utilisateur. C'est pas
quelque chose qui vient d'un service de push
notification qui va révéler service worker.
Ok, je comprends.
C'est bon ? Ok.
Ouais, merci.

Par exemple, il faut préciser.
En continualiste, alors.
T'es notification.
Après, il y a le système, donc pour ajouter
à l'accueil, qui est
très, très important quand même
sur la PWR.
C'est le petit pop-up
qui te propose au bout de... Alors, c'est des conditions
c'est... c'est pas vraiment
obscure, mais c'est un X
nombre de fois où tu viens sur
l'application. Oui,
à un moment, c'était 2 fois
quand t'es resté 5 minutes. Donc, quand t'es resté
2 fois 5 minutes sur Chrome, il la
faisait voir. Je crois que maintenant,
il l'a mis instantané. Ah, instantané, mais non.
Mais on peut, avec le code,
on peut, sur Chrome, on peut
choisir quand est-ce qu'on veut la mettre.
Donc après 5 fois, 10 minutes
ou ce qu'on veut.
Ok. Donc ça, c'est une chose qu'on peut contourner
sur Safari. Via les...
Je sais plus, les métas, je crois, les métas avec les icônes
tout ça. Donc, c'est
encore faisable.
Sur Safari, en fait, on peut pas
faire voir ce message nativement.
Mais, elle est installable. Il faut juste
que l'utilisateur sache ce qu'est
une PWVA et qu'il sache qu'il peut
l'installer, si il clique sur
option. Ouais, c'est pas vrai.
À TwomScreen.
Exactement. Et du coup, il faut
t'es obligé d'éduquer un petit peu
ton utilisateur pour lui dire, bah regarde,
tu peux la retrouver facilement.
Enregistre-la sur ton bureau.
C'est sûr. Et aujourd'hui, en dehors
des developers web ou des gens un peu plus
techniques, par exemple, mes parents
ne savent pas du tout ce que c'est.
Et ma mère n'ira pas chercher
dans les options ajoutées
à l'écran d'accueil.
Donc, ouais.
Moi, ça passe par une petite
éducation. Par exemple, il y a un
événement qui permet de savoir si l'application
est installée. Donc, pour une de nos
applications sur Chrome, donc
l'application, elle est en WebView
dans l'application native, mais aussi
desktop uniquement PWVA. Donc, j'ai
mis un événement dessus pour regarder
combien de gens l'installent, mais je m'attend pas
un grand nom. Mais on sait jamais.
Ah, je ne sais pas qui est un événement.
C'est intéressant.
OK.
OK.
Donc, WebManifest, on en est
où, alors, au niveau de Safari?
Je sais que les icônes
ne sont pas pris en charge.
Oui, les icônes, en fait,
il faut un métatag en plus
dans le azex.html. Donc,
ce n'est pas bloquant, c'est juste
une ligne encore spécifique, juste pour
Safari. Donc, oui, ce serait bien
que tout le monde soit aligné et qu'on
est le manifest, que tout le monde regarde
les mêmes propriétés et qu'on n'est pas
de choses ajoutées sur le côté, mais
ce n'est vraiment pas bloquant, il faut juste le savoir.
Mais c'est juste pour
l'icône quand on installe
l'application sur l'écran d'accueil,
l'icône qui va s'afficher, c'est juste pour
cette image. On a tendu
une ligne en plus. Parce que, justement,
depuis que l'iPhone existe,
en fait, on a toujours eu ces propriétés
via les métats, pour les icônes, pour
la couleur de la barre, etc.
Enfin, ces trucs-là, ça existait avant
l'épée de WV, en fait, ces trucs-là. Et du
coup, c'est toujours existant et ce n'est pas pris
en charge dans Safari
sur le web manifest.
Je crois que pour la couleur du fond,
maintenant, il prend sur celle de manifest.
Je crois qu'il n'y a que les icônes qui sont
à prise du manifest. Parce qu'il ne me sent pas
que j'ai une ligne de plus pour...
Donc, dans le manifest, il y a une propriété
qui s'appelle genre background. Et on
met la couleur qui va afficher
quand l'application
s'ouvre ou si on laisse
la navigation.

Les capacités
de cache.
Je crois que c'est un problème par contre.
Ça peut l'être.
Mais
il y a plusieurs
versions, parce qu'en soi,
une PWA, on veut qu'elle reste
assez légère.
Donc, si on a
une progression web assez légère,
mais qu'on cache absolument tout,
il n'y a pas trop d'intérêt.
Donc, le cache se fait
assez intelligemment. On ne va pas
absolument cacher toutes les requêtes, toutes les images.
Il faut cacher
ce qu'on veut, ce qu'on veut, ce qu'il faut
qu'il soit rendu rapidement à l'utilisateur.
Par exemple, il y a
une librairie Workbox pour les services workers.
Donc, il y a déjà toutes les stratégies
prédéfinies
et toutes les méthodes prédéfinies.
Donc,
avec
cette librairie,
on peut choisir
pour les images, par exemple,
de les mettre dans le cache,
ou pour les images ne jamais les mettre dans le cache,
ou seulement les images qui répondent
à cette regrape. Donc, on peut choisir
ce qu'on veut cache ou pas cache.
Et il y a aussi le pré-cache.
Donc, quand j'arrive sur l'application web
pour la première fois, je vais choisir
ce que je veux mettre
déjà dans le cache, même des images
qui ne sont pas requétées sur cette page
où je suis.
Donc, imagine, non, je veux que quand je fasse
une photo, je ne veux pas avoir un flow,
mais je veux quand même avoir une page sympa
qui dit, vous n'avez pas d'internet
et c'est plus tard avec une image,
je peux mettre cette image dans le cache,
donc quand l'utilisateur n'aura pas internet,
je peux quand même montrer cette page.
Parce que ce sera dans le cache,
et elle sera disponible même si l'utilisateur
n'a jamais été sur cette page
pour requêter l'image avant.
Donc, il y a pas mal de stratégies
pour ça, mais
en soi, les progressives web
ne devraient pas faire
tant de megabytes de cache.
Donc,
je sais découvert ça il y a quelques mois.
Donc, ce n'est pas un problème.
Par exemple, pour nos applications
aujourd'hui dans mon entreprise,
on dépasse pas 50 megabytes.
Donc, ce n'est pas un problème.
D'accord.
Donc, pour toi, c'est pas...
Le cache,
ce n'est pas vraiment un problème.
C'est juste qu'il faut gérer correctement.
Et si jamais ça dépasse,
certaines choses ne tiendront pas dans le cache,
mais ça n'empêche pas que le reste
sera toujours rendu.
Donc, pareil, ce n'est pas bloquant,
et ça ne devrait pas être un problème.
D'ailleurs, c'est pour ça qu'ils ont choisi
cette limite.
Tu penses que 50 megabytes, c'est déjà bien suffisant pour...
Ouais, parce qu'ok, si on cache
1000 images,
1000 consumes,
ce n'est pas le but de tout cacher non plus.
Et du coup, ouais, t'avais marqué une note
dans les notes de l'épisode.
Comme quoi, iOS purge
après plusieurs jours. C'est moi qui ai marqué ça, peut-être.
Non, ouais, c'est tous les deux en fait, je crois.
Oui, parce qu'on a un support ticket
à cause de ça, parce que les clients
étaient tout le temps déconnectés.
Ouais, c'est ça. En fait, c'est pure.
Après quelques jours, tout le cache, en fait,
sur iOS. C'est ça.
Après quelques jours, ça dépend
des versions de WebKit. Il y a une version
assez récente, c'est un jour.
Donc si la personne ne va pas sur l'application
pendant un jour,
elle est plus connectée,
ça dépend ce qu'on a mis dans le cache ou les cookies.
Donc, ouais, ça devra
se faire une première expérience
sur l'application Web quand il revient, quoi.
Donc il a besoin de se reconnecter,
rien n'est caché.
Donc...
Ça, c'est moyen. Ouais, c'est pas top.
C'est pas top. Surtout le un jour,
parce qu'il y a un jour,
une semaine, un mois, un an,
selon la version de WebKit.
Ouais. Une semaine,
parce que nous, quand le usinateur,
par exemple, se connecte et qu'on
garde
sa carte
de filetée dans les cookies,
on peut pouvoir le connecter quand il revient.
Donc
quand on le met dans les cookies, on met
une date, imaginant un an,
donc on... imaginant fin d'année 2020.
Quand il va revenir sur l'application,
un jour plus tard, ce sera toujours fin d'année 2020.
Mais ça farie.
Si on met fin d'année 2020,
il va se dire, non, j'ai cette version
de WebKit, il va
mettre la date du cookie,
ce sera la semaine prochaine.
Donc, si l'usinateur revient 2 jours après,
ce sera toujours la semaine prochaine par rapport
à la fois où on a mis les cookies,
donc, imaginons, il reste plus que 5 jours.
Donc, nous, ce qu'on a fait,
si l'usinateur revient, c'est que
à chaque fois qu'il revient,
on remet une nouvelle date de cookie, donc
à chaque fois, on lui remet une semaine.
Le maximum que ça farie, puisse se mettre.
Le hack.
Parce qu'on a eu
des support tickets à cause de ça
assez récemment.
Un jour, c'est
limite, si tu vas te connecter
à chaque fois que tu reviens sur l'app
tous les jours, c'est un peu relou.
Oui, parce qu'encore une semaine à
moi, qu'il faut que l'utilisateur
y a place souvent. Une semaine,
à la limite, ça passe, tu dis, je ne me suis pas connecté
depuis une semaine, c'est normal, mais tous les jours,
c'est chaud.
Donc, c'est
pas bloquant, c'est ennuyeux,
mais bon.
On essaie de trouver
des choses pour améliorer
l'expérience utilisateur,
malgré ça.
Il y avait aussi
les background 5
qui ne sont pas pris en charge, mais
ce n'est pas forcément un truc qu'on utilise beaucoup.
Vous l'utilisez beaucoup ça ?
Non, ça, c'est plutôt...
C'est bien, par exemple, pour un mod
hors ligne assez complet, donc imaginons,
je n'ai pas d'internet, je rend la page
telle que l'utilisateur
l'a vue avant, quand il avait
internet.
Et on peut sauvegarder, par exemple,
tous les résultats, par exemple,
son dernier nombre de timbres, ces transactions,
on affiche tout comme s'il était en ligne,
parce qu'on a cache, par exemple.
Et s'il fait des actions,
il a l'impression qu'il fait des actions comme
s'il avait de la connexion, et en fait, elles seront
toutes faites quand la connexion
sera vraiment là.
Donc, c'est vraiment pour avoir une super bonne
expérience, sans internet, ou avec très
peu d'internet, on l'utilise pas.
Mais
c'est un bon plus.
Mais ça, ça ne marche pas
sur Safari ? Oui, ça, c'est sûr.
Ok.
De ce que j'ai vu, je n'ai pas implémenté de la fonctionnalité.
Alors, comment ils font
Firebase ?
Parce que moi, j'ai fait un petit
projet pour mon école de skill,
où on synchronise
le nombre de personnes
qui ont part
en repiste, pour que tout le monde
soit au courant
avec combien de clients on part
en repiste.
Et ça, en temps réel.
Et parfois, en fait, on a des zones
sur la zone en montagne, où
ce n'est pas du tout synchronisé.
Et moi, j'ai fait
une petite pay-doule VAM, et j'utilise
énormément de
codes de Firebase pour éviter.
Et ils ont un truc qui s'appelle
Persistent Data.
Et en fait, ça envoie mon action.
Et je me mets en orling,
volontairement. J'envoie mon action.
Et quand je me reconnecte
au réseau,
ma notification
part.
Non, excusez-moi.
Ma déclare
au serveur, ça part.
Et donc,
si ce n'est pas un background sync,
c'est un autre truc spécial
à Firebase,
où ils utilisent leurs propres apais
ou autre chose.
Je ne suis pas sûre, mais j'ai vérifié
que
c'est sûr que ce n'est pas supporté.
Je t'ai mis le lien dans le chat.
Can I use ?
Mais j'ai vu que
oui, il y a d'autres liens en passant
par index DB
pour simuler ce comportement.
Donc, pareil, ce n'est pas impossible. Il y a d'autres liens
que je ne connais pas. J'ai jamais implémenté cette fonctionnalité.
Alors, pour le coup,
je vais creuser.
Parce qu'en fait, avec Firebase,
ils ont un truc, c'est juste magique,
tu fais enable, persistent,
un truc comme ça.
Et, ça marche
en ligne.
Donc, c'est assez bluffant.
J'avoue, j'ai été assez fainé
et je n'ai même pas regardé
le comportement de
ce qui se passait derrière.
Par contre, ce qui est sûr,
c'est que ça marche. Ils doivent contourner
le truc. Je sais que
Firebase utilise index DB.
Donc, peut-être qu'ils ne utilisent
pas le background sync
avec la pays, mais ils utilisent
une autre stratégie de comportement,
de contournement avec index DB.
Oui, ça, c'est possible.
Je l'ai noté, je regarderai aussi,
ça m'intéresse.
Parce qu'on veut avoir
un mode hors ligne
dans nos prochaines fonctionnalités.
Donc, bon,
sa farie va peut-être être bloquant.
Donc, peut-être que ça va résoudre quelques problèmes.
Donc, merci. Je regarderai ça.
Mais oui,
Firebase, ils ont un truc...
Pour le coup, moi, j'ai fait le test
et ça marche, quoi.
Ça marche vraiment.
Oui, je suis sûr que ça marche.
Mais j'ai vu qu'il y avait des parallèles
au background sync, donc...
C'est possible.
Mais c'est là où c'est trop fort,
c'est qu'ils arrivent... enfin,
il y a toujours des stratégies de comportement
de contournement, je trouve ça super intéressant.
Après, c'est comme si
il y a toujours un
qui fait un peu...
qui freine
des cas de fer
sur plein de nouvelles technos,
quoi. Et je trouve ça...
Je trouve ça un peu bête,
si les standards évoluent.
Et après, on va
s'écarter un peu
des specs
purs. Mais
pourquoi sa farie
fait... et le mouton noir,
quoi. Parce que Apple freine
à blindes.
Ok. Pourquoi ?
Est-ce qu'il y a vraiment une raison technique
ou c'est juste une raison
économique de garder
un système d'app
avec tout le récosystème ?
Justement, c'est très bien
la transition, parce que
l'actualité
nous donne un peu des pistes, quoi.
Donc on se rend compte un peu que, aujourd'hui,
les revenus d'Apple
viennent beaucoup du store, des applications.
Et...
on peut très bien penser que, ouais, ça les
n'intéresse pas de faire de la pwa, parce qu'ils veulent
garder tout sur le store, quoi.
Enfin moi, ça fait longtemps qu'on le soupçonne,
mais je ne sais pas ce que vous en pensez,
mais on a vraiment l'impression, là,
qu'ils ne veulent pas vraiment que ça sort du store.
J'ai l'impression.
Oui, c'est vrai surtout,
parce qu'ils empêchent
aussi que les pwa arrivent sur le store.
Donc, il y a plein de conditions
respectées, à voir le...
chez le tour, donc c'est assez dur.
Après, je pense qu'il y a aussi des parties techniques,
par exemple les push notifications sur iOS Android
ne fonctionnent pas de la même façon.
Et pour des raisons
sécurité ou allumiement du code,
ils essaient
de freiner cette fonctionnalité, qui est apparemment
en développement, mais on ne sait pas.
Elle n'est pas dans la prochaine version de iOS
14, ça c'est sûr.
Mais...
non, ils... enfin...
Ils continuent quand même de faire des applications
pour le web. La prochaine, donc,
il y a une version 14
de iOS qui va sortir.
Et ils ont
l'API pour Face ID et Touch ID.
La web authentification
API. Donc, ils continuent
quand même de faire... oui, ils continuent
de faire des fonctionnalités pour le web. Ils ne sont pas
anti-progressive web app.
D'ailleurs, ils refusent des fois
des personnes... des applications
store et leur disent,
c'est pas une application.
Vaut mieux en faire une web application.
Donc, ils ne sont pas contre
les web apps.
Moi, je pense qu'ils n'aiment pas trop le terme
progressive web app. C'est un peu trop
Google term. Mais...
Non, ils continuent de développer
pas mal de fonctionnalités sur le web.
Non, pas toutes.
Mais...
Après, ok.
Alors, ils implémentent
des nouvelles fonctionnalités.
Mais, ça reste quand même
timide. Quand on sait
leur force de production
on parle même pas de la
capitisation boursière
ou carrément, ils peuvent faire ce qu'ils veulent.
Donc, s'ils veulent mettre des moyens là-dedans
ils peuvent le faire.
Donc, s'ils le font pas
je pense qu'il y a
une raison voulu.
Ça fait partie de leur stratégie.
La question,
c'est est-ce qu'à un moment
ils ne seront pas obligés
de le faire ?
Alors, peut-être
moi je suis un peu assez extérieur à ça, mais j'ai
l'impression que ça commence un peu
à bouger
et que Google joue bien le jeu
et pousse complet
là-dedans.
Parce qu'ils sont forces de proposition.
Ils implémentent des choses.
Mozilla, pareil.
Ils poussent aussi.
Est-ce qu'à un moment donné
est-ce qu'on réussira
à faire plier Apple ?
Je ne sais pas.
Ils développent des choses.
Ce n'est pas un nom
catégorique
et on ne veut pas développer pour les PWA.
Après, ça va doucement.
Mais oui, ils sont poussés.
Par exemple, les pushes notifications, c'est vraiment
quelque chose que la communauté pousse.
Parce que ça peut être un bloc
parce qu'on ne faut pas séparer une application native.
Ça demande beaucoup plus de travail.
Donc, oui, la communauté pousse
et il délivre
des choses.
Il délivre des nouvelles features
pour le web.
Après, je ne suis pas trop
une personne Apple.

je suis ce qui
délivre.
Il continue de délivrer pour le web.
Donc, ce n'est pas tout négatif.
Après, oui, c'est sûr, c'est bloquant.
Même pour
le CSS.
Quand on fait une application
et qu'on voit que le scrolling
est cassé sur
Safari iOS.
Safari, c'est devenu un petit peu
Explorer 6.
C'est un peu ça, en ce moment.
En fait, Safari 2020,
c'est le iOS 2D.
C'est ça, en fait.
Des fois, tu as des trucs qui sont pétés sur Safari.
Ce n'est pas pourquoi.
Après,
je vais faire l'avocat de Diable.
Avec
Safari, Apple résiste un peu
d'un autre côté.
Aujourd'hui, on n'a quasiment que du Chrome
sur tous les navigateurs.
Firefox,
pour l'instant, ça va, mais combien de temps, on ne sait pas.
Google
fait un peu sa loi.
On pose un peu ses standards,
les imposes un peu à tout le monde.
D'un autre côté, Safari
on comprend un peu l'intérêt de ne pas
faire la pwr, mais
quel est l'intérêt pour Google
de pousser les pwr ?
C'est ça aussi la question.
Est-ce que ça leur permet de
contrôler un peu plus de choses, d'être
je ne sais pas,
d'autant plus que s'il me semble que le
nouveau Edge
c'est Chromium.
Ça sera Chromium.
En fait,
c'est l'hégémonie de Chromium.
Est-ce que Safari
ne veut pas garder
du pouvoir
contre l'hégémonie de Chromium ?
Ben
Le truc,
là on n'est quasiment que du Chromium
partout.
Google impose ses règles.
Ouais,
ils ont tendance
même des sur Twitter,
t'as pas mal d'ingénieurs chez Google
qui bâchent pas mal sur Safari
parce qu'il y a des choses qui ne sont pas implémentées
ou le CSS
qui est cassé.
Ils sont assez méchants
contre Safari.
Moi je défend aussi un peu Apple
peut-être, c'est peut-être pas si mal
de résister un petit peu.
Même si franchement il y a certaines choses
qui auraient pu déjà implémenter
tout ce qui est icône, tout ça,
ça ne va pas être très compliqué à implémenter.
Ils ont des milliers de développeurs.
Franchement,
ça me pose.
Oui, non, c'est sûr.
Après,
le truc
c'est que Apple
tout le monde a son mot à dire
parce que Google va pousser
pour les standards mais ils ne peuvent pas
vraiment les imposer.
Mozia Firefox et Apple Safari
ont aussi leur mot à dire.
Tout le monde participe au standard.
Apple et Mozia peuvent aussi
proposer leur standard. Il y a une communauté
qui est très intéressante.
Ils ont tous un poids.
Google pousse un peu plus
mais ça peut être aussi refusé.

Google a beaucoup de pouvoirs, ils ne les a pas tous.
Il y a pas mal
de navigateurs sous chromium.
Maintenant, il y a Microsoft Edge,
Google
mais il reste toujours Mozia
et Mozia Firefox et Safari.
Donc ça fait quand même 3 bons navigateurs
qui peuvent proposer des standards.
Donc Google
pousse pour le web.
Il fait pas mal de fonctionnalités
pour se rapprocher des applications natives.
Je ne suis pas sûr qu'elle est le
goal final, qu'elle est l'objectif final
si c'est de remplacer les applications
natives carrément, ne plus avoir
de Google Store ou quoi.
Mais pour l'instant, ça nous permet
d'avoir le choix, d'avoir
une application web seulement
ou d'avoir une application web et natif
de faire des trucs cool avec les deux
ensemble.
Donc on a déjà beaucoup plus de choix
que quelques années
il y a 5 ou 10 ans.
Donc je ne pense pas que ce soit
que une mauvaise chose parce que si Google
n'était pas là, le web avancerait
beaucoup moins vite. Donc il fait
avancer le web. Après,
il ne faut pas que ça vienne trop dangereux,
qui ait trop de pouvoirs, ou de licences
propriétaires
et de contrôler un peu tout.
Mais
pour l'instant, il y a
un certain équilibre, il ne faudrait pas qu'il penche
trop.
Mais Modia et
Safari
ne peuvent pas aussi proposer des standards
et leurs mots à dire
dans tout ça.
Pour l'instant, tout le monde
participe.
Après, quand on voit qu'aujourd'hui
iOS
et la frontière entre
iOS et macOS est en train de se réduire
on arrive
sur des mêmes designs
donc ils veulent porter des applications
que le porte
que la portabilité d'une appli
desktop, à une appli
iPad soit de plus
en plus facile.
Ca manque un petit peu d'ouverture
tout ça. Moi, c'est le seul truc
et pourtant je suis Apple
j'ai un Mac et tout ça
j'adore les produits Apple
mais
le trust et les gémonies
je trouve ça dangereux
et moi je ne voudrais pas être enfermé dans un système
et je trouve justement que les web est beaucoup plus
ouvert
à des
bref, en tout cas pour moi
c'est plutôt des valeurs d'ouverture
et
pour moi Apple
ne joue pas à fond ce jeu-là
il joue un peu mais
ça reste trop timide à mon goût
et j'espère
que demain ce sera mieux
ce ne sera pas pour la prochaine version
d'IOS en tout cas
malheureusement
on rattendra
encore un an
après il y a plein de forums
où on pose la question
il n'y a pas de réponse
c'est comme les push notifications
ça fait un moment qu'on les attend
et à chaque nouvelle version
on est déçus
ça fait un moment
je vois déjà en 2018
c'est vrai que souvent quand tu parles de PWA
des marketeux
c'est souvent les notifications qui les intéressent
pour que Marie
et tant que ça ne sera pas
facile à implémenter sur les deux plateformes
enfin sur Android et IOS
ça sera toujours un petit frein
je pense
même si c'est
si le réalise aujourd'hui
ce ne sera que sur la dernière version
mais qu'est ce qu'on fait des anciennes versions
elles n'ont pas de notifications
donc ça va prendre du temps
que tout le monde ait des versions qui supportent
les push notifications
après de ce côté-là
IOS a un avantage par rapport à Android
il n'y a pas une grosse fragmentation
souvent les versions
sont installées assez rapidement
elle est assez forte en général
à part si vraiment
tu as un vieux téléphone
donc là tu ne pourras pas le monter
mais ça c'est l'avantage sur Apple
c'est que c'est vite implémenté
pour les nouvelles versions
mais bon
par exemple nous je sais qu'il y a des clients
qui supportent des versions assez basses
que nous si on veut
supporter avec nos fonctionnalités actuelles
il faut qu'on fasse
soit des polyfil ou soit qu'on
change notre code parce qu'on ne peut pas supporter
par exemple IOS 9
mais
ouais
ouais mais leur application native
le support donc sur mes webviews
ils s'attendent à ce qu'on suit
ouais le problème c'est les webviews
c'est là où vous êtes confrontés
oui parce que
oui exactement
parce que si du coup on a
une page non supportée qui dit
qu'en gros
l'utilisateur doit mettre un jour son OS
ou son navigateur
pour pouvoir voir notre webview
au plus bas
et oui quand on vend notre partie web on dit clairement
donc c'est ce qu'on supporte
ça prend de l'essai on va pas
c'est comme on a une autre dernière
application web survivante
c'est pour
choisir
ce que le supermarché va mettre dans son programme
donc c'est quelque chose d'interne
et du coup ils utilisent des vieilles machines
et ils veulent toujours supporter Internet Explorer
non
et même là
pour notre prochain programme
avec PWVA
il y a un client
qui veut Internet Explorer
et on leur dit non c'est pas possible
sinon faut qu'on refait l'app
juste pour avoir un build Internet Explorer
oui
donc oui les clients
sont assez demandants et eux ils ont
des utilisateurs
de tout navigateur de toute version
de très très vieux et il va
supporter tout le monde donc
pour Internet Explorer
déjà la bonne nouvelle
c'est que dans un an
à peu près
il sera totalement abandonné par Microsoft
c'est dans un an
ça a été annoncé il y a quelques jours
dans un an c'est fini
non c'est dans un jour
normalement tu ne le supportes plus aujourd'hui
parce que c'est une vraie passe au niveau sécurité
mais
là c'est officiel dans un an c'est terminé
donc les clients
c'est une bonne nouvelle
bon argument pour leur dire non c'est fini
après c'est un truc interne donc
ça pas besoin d'être super rapide
parce qu'ils seront en wifi de toute façon
dans les bureaux ça pas besoin
d'avoir des animations ou quoi que ce soit
donc ça passe mais on a beaucoup
de polyfill juste pour Internet Explorer
en fait du coup
dans un an ils arrêtent
et aident un support
pour les applications parce que souvent
c'est un souci d'application
en interne qu'ils utilisent qui ont pas type
avec Explorer c'est le problème que j'ai
avec les clients suisses
et avec des systèmes de Java et tout ça
et en fait Edge va embarquer un mode
pour faire tourner les anciennes applications
du coup il y a plus de raisons
de continuer à utiliser Internet Explorer
ok
moi c'est plutôt une bonne nouvelle
ah oui très bonne nouvelle pour tout le monde
on aurait les clients qui arrêtent
en nous demander de faire une PWAS
qui puisse être supportée sur Internet Explorer
rien que la question est drôle
oui c'est clair
ok
du coup
bah voilà
je pense que
en tout cas on a vu qu'il n'y a pas vraiment
de raison de ne pas faire de PWAS
puisque même sur Safari
on arrive à contourner
ce qui n'est pas pris en charge
oui que n'importe quelle
application web
peut se définir en tant que PWAS
pour avoir quelques features sur une application web
qui est déjà existante
de toute façon c'est sale pour un cible c'est progressible
donc tu impléments de petit à petit
des features
jusqu'à ce que ton navigateur prenne tout en charge
c'est un gros cesseal concept
ok
un truc à rajouter
top non
en tout cas pas pour moi
super écoute Stéphanie
très intéressant
en tout cas on voit que tu connais bien le sujet
et que je l'aime bien
tu l'aimes bien et en plus je pense que
tu t'es bien pris la tête sur pas mal de soucis
avec Safari et les compagnies
intéressant
intéressant tout ça
on est contents d'avoir pu partager ça
merci les devenus
et Alex
donc comme d'habitude on va rappeler
nos auditeurs
c'est quand même pas mal
parce que si vous êtes restés jusque là
c'est que vous aimez quand même
l'épisode et
l'émission donc c'est plutôt cool et on a vraiment besoin de vous
du coup
parlez du podcast à vos copains
balancer l'info, aller mettre un petit commentaire
si vous pouvez
sur les plateformes
et puis partager
au maximum l'information
on en a besoin
en tout cas un grand merci Stéphanie
pour ton temps
merci à vous
merci beaucoup
et puis on se retrouve pour un prochain épisode
à plus
à plus ciao