Je claque du web partout, sauf sur le web

Je crois que j’ai toujours aimé faire du web.

Comme beaucoup, j’ai d’abord « bidouillé » sur mes premiers ordinateurs pendant les années collège, pas mal de jeux certes, mais très vite aussi, du code. A l’époque (#papiremi), j’achetais des magazines pour débutant, il fallait retaper des pages et des pages de code pour arriver à créer quelque chose. Du Java (que j’ai très vite vomi), du Turbo Pascal ou encore du GwBasic sous DOS. C’était très cool de dessiner une tête de Bart Simpson, mais le faire en tapant des pages de LINE() ou de coder un jeu textuel par centaines de if/else, c’était surtout loin d’être fun.

Et puis je découvre HTML. En 20 lignes de code j’avais quelque chose à l’écran. L’ubiquité du langage aussi, autant dans sa rédaction que dans son exécution. Je pouvais apprendre à coder et tester mes pages aussi bien sous Windows ⁹⁵⁄₉₈ que sous BeOS (#papiremi, là encore).
D’ailleurs, un format de fichier interactif codé en 2000 et qui fonctionne encore aujourd’hui aussi bien sur un PC, une liseuse, un smartphone, une télé ou un frigo, quelque soit l’OS dessus, je ne vois que HTML.

Ce nouveau terrain de jeu, je décide d’en faire mon métier dès la sortie du lycée. Alors oui, comme la plupart d’entre vous qui avez aussi fait du web votre métier, on travaille surtout à la création ou l’évolution de sites web, applis web, emailings ou bannières. Le hasard des rencontres et des technos m’a fait faire du web en HTML/CSS comme en Flash, en PHP comme en ABAP, pour de l’i‑mode comme de la fibre, pour afficher sur un écran ou simplement être exécuté.
Ce que je trouve passionnant là-dedans, c’est que bien que ne faisant « rien d’autre » que du web (pas de natif, compilé), en un peu plus de 15 ans, je n’ai jamais fait le même métier ou bossé sur les mêmes types de projets plus de 3 ans. Et tout ça m’amène aujourd’hui à coder ou piloter « des choses », toujours avec des technos ou langage web, mais qui n’ont peu ou plus rien à voir avec un site web.

Truck PhotoBooth

TheBuddiz est un concept simple et sympa : une cabine photo dans un van VW. La demande était simple : pouvoir se prendre en photo une ou 4 fois, et imprimer la/les photo(s) sur un gabarit prédéfini par événement. Et que tout fonctionne hors ligne. Dans le van, on a donc un PC, une imprimante photo pro et une webcam HD.

Le reste, c’est une page web en local affichée plein écran avec Firefox, et une CSS print pour ne garder que la photo lors de l’impression. Le montage entre la/les photo(s) et un gabarit PNG par dessus est fait via canvas en JS.

Vitrine Transparente

Suite à une demande de LG de faire quelque chose de plus innovant que des frigos publicitaires. Mon boss de l’époque l’a rendu tactile et en a fait une étagère interactive. Parfait pour exposer des produits fragiles (antiquité, pièce de collection, objet peu manipulable…) ou dont la forme n’évoque pas l’étendue de ses capacités (montres connectées, casque de VR, …). Et côté appli, j’ai là aussi créé une page web, plein écran, via un mini PC dans le meuble. Les animations d’apparition ne sont rien de plus que des pseudo-éléments avec un border-radius au max et une transition scale de 10 à 400% dans une DIV en overflow hidden.

Tablette connectée

La demande était de pouvoir lancer un contenu sur une tablette, et le voir sur X écrans face à soi. Le but est de pouvoir comparer les téléviseurs pour un même contenu, que l’on soit plus jeu vidéo, foot ou concert. Ici, ce n’est pas un mais deux écrans qui affichent chacun une page web plein écran, un sur la tablette et un sur un bon PC, qui communiquent entre eux via websocket. Un bon PC 4K où tourne le serveur web affiche aussi la page sur les écrans, et la tablette qui s’y connecte, pour afficher une autre page web stockée elle aussi sur le PC.

Affichage dynamique interactif

On les voit partout, ces écrans d’affichage dynamique, en magasin comme dans la rue. La plupart sont des boîtiers vidéos prévus pour faire tourner des vidéos en boucle. En les remplaçant par un mini PC, une page web plein écran et du websocket (+ une page web quand même pour le smartphone, certes), ça devient beaucoup plus intéressant :) Le but ici était d’animer le hall d’accueil du siège pendant l’Euro de foot 2016 et faire gagner des lots aux collaborateur tout en leur faisant découvrir la possibilité d’interaction smartphone -> écran.

Autre but mais même concept, avec un salon de l’innovation à Dubai. Là aussi, pour faire découvrir la possibilité d’interaction smartphone -> écran.

Dans ces deux démos, que ce soit côté smartphone ou côté écran, tout est fait avec des DIV, du JS et des CSS transform / animation.

Toujours 100 % web, l’affichage des produits non présents en magasin sur un écran en taille réelle (d’où sa taille > 84’’ pour y faire rentrer un frigo). Une appli sur la borne permet de projeter le visuel produit sur l’écran, et une API sur un mini pc en magasin permet aux smartphones vendeurs de le faire aussi. Ici, aucun accès web autre que local.

Meuble LED

Bon ok là on s’écarte un peu du web, mais on reste sur des technos web. Je vous épargne la partie câblage / électricité, mais côté pilotage des LEDs, c’est sur le même mini PC qui affiche l’appli (en bas à droite) que tourne un serveur NodeJS qui pilote une carte AdaFruit via un flux JSON. Le but étant de pouvoir changer la répartition des couleurs / segmentation produits très rapidement.

Contenu vidéo live

Dans un but encore différent, une page web plein écran qui sert de source vidéo à une régie. Sur la page, un gros rectangle vert sert à la régie vidéo pour y incruster le live cam. Le bloc de droite est lui connecté à l’API Twitter et sert de Live Social Wall (mais ça pourrait être tout autre chose).

Le résultat était affiché sur écran géant en extérieur, en intérieur et dans les salles du cinéma à l’occasion de l’avant-première d’un blockbuster avec présence des artistes.

Borne tactile d’extension de gamme

Peut-être plus classique pour finir, une borne tactile en magasin qui permet de retrouver une sélection de catégories de produits disponible en ligne, et pas dans le magasin. Une application web plein écran permet aussi aux visiteurs de faire une pré-sélection de produits et de l’imprimer sur un ticket via une imprimante thermique intégrée dans la borne.

Les vendeurs peuvent récupérer les pré-sélections depuis les iPad pour finaliser la commande et de faire livrer le client chez lui ou en magasin.

Un autre web

Pour suivre ma chronologie du web (et que beaucoup doivent partager) je suis passé de HTML4 à xHTML, puis Flash, puis au HTML5 en même temps que le mobile first. À chaque « nouveau web » ses nouvelles règles, problématiques, bonnes pratiques. Cet « autre web » ne déroge pas à la règle.

Ce qui a été assez troublant au début, c’est de se forcer à voir ces dispositifs comme de l’applicatif codé en web, et pas comme du web applicatif. Les PWA (Progressive Web App) c’est très bien, mais j’imagine mal la stabilité de Chrome avec des dizaines de gigas de data en mémoire via ServiceWorker… C’est bien un applicatif que l’on doit imaginer, comme pouvoir être copié par clé USB sur une machine lambda. Et pourquoi pas être mis à jour par clé USB sans perte de données.

Autre point, probablement le plus gros : tout doit fonctionner 100 % hors-ligne. Pas en fallback si le web coupe, mais bien fonctionner en local. Et l’applicatif et les données doivent être mis à jour à intervalle régulier par une tâche annexe. Du vrai 100 % offline-first.
Pour des raisons de fluidité déjà, mais aussi parce qu’une connexion web, ça coupe, et même un datacentre peut se vautrer (#ovhgate). Or, pour votre écran à l’autre bout du pays, voire de l’Europe, il n’y a personne pour faire F5 (et dans la plupart des cas il n’y a d’ailleurs même pas de clavier). Quand corriger un bug sur un site n’est « que » pousser des fichiers en FTP ou pousser un commit, c’est ici une phase de déploiement qui peut prendre plusieurs jours, et nécessiter une intervention humaine sur place.

Dernier point qui a son importance, à la différence d’un site web, la page reste affichée. Pas quelques dizaines minutes, mais entre quelques dizaines d’heures et plusieurs semaines. Et rester en prod parfois sans mise à jour possible pendant 3 à 4 ans. Autant le offline-first permet de se passer complètement de la minification des ressources textes ou des sprites CSS, mais le moindre petit JS de trop, surtout s’il n’est pas optimisé, peut faire monter en charge CPU ou mémoire. Exit donc le dev front en mode pendule de cristal de librairies empilées, il faut (réapprendre à) coder soi-même en mode nazi de la perf et de la stabilité. En contrepartie, c’est un seul OS, un seul navigateur, une seule résolution d’écran, tournant sur un seul matériel de votre choix.

C’est un autre web, mais pour moi c’est surtout un nouveau terrain de jeu, et c’est vraiment ça que j’adore dans ce métier.