5 min de lecture
Comment nous construisons nopa, partie 2
Dans la première partie, j’avais promis d’ouvrir le capot. Le voici : pourquoi nopa n’a pas de backend, comment le travail lourd tient dans un onglet du navigateur, où vit ce que vous faites — et comment vérifier chaque mot de ceci vous-même en une minute.
Il n’y a nulle part où envoyer
La plupart des sites d’outils sont une page devant un serveur : votre fichier monte, le serveur travaille, le résultat redescend. nopa fait l’inverse. Le site, ce sont des fichiers statiques — HTML, JavaScript, polices — et c’est le code qui vient à vous, pas votre fichier qui va à lui. Quand vous fusionnez deux PDF, la fusion se fait dans votre onglet, et le PDF n’en sort pas.
C’est aussi pour ça qu’il n’y a pas de compte. Un compte sert à garder quelque chose à vous sur un serveur, et aucun serveur ne garde rien : il n’y a donc nulle part où se connecter.
Le travail lourd, dans un onglet
Le navigateur est devenu une vraie machine, et chaque outil en utilise la partie qui convient à sa tâche :
- PDF : pdf-lib construit et réécrit le fichier, PDF.js dessine les pages que vous voyez. Compressez un PDF, et les deux tournent sur votre appareil.
- Photos et audio : des réseaux de neurones tournent en WebAssembly sur ONNX Runtime. Les outils pour enlever le fond et transcrire un audio téléchargent leur modèle une fois et le gardent ; votre photo va au modèle, jamais l’inverse.
- Scans : tesseract.js lit le texte d’une page scannée dans un thread à part. La première fois, il télécharge un modèle de lecture de 4 à 5 Mo ; ensuite, il est déjà là.
- Fichiers Word : mammoth lit un .docx et docx le réécrit, si bien que l’éditeur Word ouvre le contrat qu’on vous a envoyé et vous le rend en vrai fichier Word.
- Jeux : jsnes fait tourner une NES entière en JavaScript. La page NES embarque deux jeux homebrew dont les auteurs l’autorisent, et lit votre propre fichier .nes sans l’envoyer nulle part.
Le prix : le code doit venir jusqu’à vous
Il y a un revers. Un outil côté serveur vous envoie une page légère et fait le gros du travail là où vous ne le voyez pas ; nous devons vous envoyer le gros du travail. Alors nous le comptons : un script de notre dépôt ouvre chaque page dans un vrai navigateur et additionne le JavaScript téléchargé avant que vous n’appuyiez sur quoi que ce soit. Le premier passage a trouvé des pages qui tiraient 1,4 Mo pour rien — l’histoire complète, chiffres compris, est dans un article précédent.
La règle depuis : un moteur se charge quand on appuie sur son bouton. Le moteur PDF arrive quand vous ouvrez un PDF, le modèle de lecture quand vous demandez à lire un scan. Cette semaine, la règle a attrapé un cas de plus : le tableau téléchargeait une bibliothèque PDF de 170 Ko à chaque ouverture, pour une seule option de menu.
Où vit votre travail
Ce que vous enregistrez — un tableau, une liste de tâches, un document, les fichiers que produisent les outils — va dans IndexedDB, la base de données du navigateur lui-même, sur votre appareil. Les applications enregistrent au fil du travail : fermez l’onglet, tout est là où vous l’avez laissé.
La partie honnête : ce stockage appartient à ce navigateur. Effacez les données du site, il disparaît ; prenez votre téléphone, il n’y est pas. La sauvegarde est donc à un clic — tout le bureau en un seul fichier, dans Réglages → Données — et le même écran permet de demander au navigateur de ne pas effacer nopa quand le disque se remplit.
Hors ligne, après la première visite
Un service worker garde une copie de l’application sur votre appareil : une fois nopa ouvert, les outils s’ouvrent sans connexion. Tout n’est pas stocké d’avance : les modèles de réseaux de neurones et le modèle de lecture ne se téléchargent que quand un outil en a besoin, parce qu’un téléphone n’a pas à garder cent mégaoctets de modèles au cas où.
Vérifiez par vous-même
Ouvrez les outils de développement de votre navigateur, passez sur l’onglet Network et utilisez n’importe quel outil. Vous verrez deux sortes de requêtes : notre propre code qui arrive de nopa.space, et des statistiques de visite pour Yandex Metrica et PostHog — quelle page a été ouverte, quel outil utilisé. Vous ne verrez pas votre fichier partir où que ce soit, parce qu’il ne part pas. Un bloqueur de contenu coupe les statistiques, et tous les outils marchent pareil.
Nous nous sommes trompés là-dessus une fois. Le panneau de nos pages produit promettait « pas un seul POST » — mesuré sur une version sans statistiques, alors qu’en production le compteur envoie ses propres POST. Un lecteur l’aurait vu en dix secondes ; nous l’avons vu cette semaine et réécrit le panneau pour qu’il dise exactement ce que vous verrez.
Ce que cette conception ne sait pas faire
Un serveur fait des choses qu’un onglet ne fait pas, et nous préférons le dire :
- Pas de synchronisation. Votre téléphone et votre ordinateur gardent chacun leur copie ; un fichier de sauvegarde la transporte, un lien en direct n’existe pas.
- Pas de collaboration en temps réel. Deux personnes sur un même tableau ont besoin d’un serveur entre elles.
- Le premier lancement d’un outil d’IA attend le téléchargement de son modèle.
- Un téléphone est plus lent qu’un centre de données. La plupart des tâches prennent un instant ; une heure d’audio prend un moment.
La suite
Si quelque chose casse sur votre appareil ou s’il vous manque un outil, écrivez à hello@nopa.space — une vraie personne lit. Ou commencez par le catalogue ; la première partie, sur la raison d’être de nopa, est ici.