Partager une base de code entre une application de bureau et sa version navigateur ne divise pas le travail par deux. Sur Arti — notre éditeur de plans pour macOS, également disponible dans un navigateur — la logique métier a été réutilisée à l'identique, mais la version web a demandé son propre travail d'hébergement, son propre système de remontée de plantages et ses propres contraintes de chargement. Le code se partage ; la mise en production, non.

Cet article part d'un cas réel plutôt que d'un principe. Les chiffres ci-dessous ont été mesurés sur le déploiement en ligne, pas estimés.

Ce qui se partage réellement

La réponse courte : presque tout ce que vous avez écrit, et rien de ce qui l'entoure. Sur Arti, l'intégralité de l'éditeur est commune aux deux plateformes — le dessin des pièces, les portes et fenêtres qui percent de vraies ouvertures, les 244 meubles aux dimensions réelles, le passage en 3D, l'export. Il n'existe pas de seconde implémentation à tenir à jour, et une correction faite une fois vaut pour les deux.

Ce qui ne se partage pas, c'est la couche qui touche au système : l'endroit où les fichiers sont rangés, la façon dont une exportation est enregistrée, et la manière dont un plantage est signalé. Ces trois points paraissent secondaires sur un planning. Ce sont eux qui prennent le temps.

Le stockage change de nature, et le discours avec lui

Sur le Mac, un plan est un fichier dans le conteneur de l'application : il survit à une mise à jour, il part dans la sauvegarde Time Machine, il vous appartient au sens le plus simple du terme.

Dans un navigateur, le même plan vit dans le stockage du navigateur, sur cette machine-là. Rien n'est envoyé nulle part — la promesse « vos données ne partent pas » reste vraie — mais l'utilisateur peut l'effacer sans le savoir en vidant les données du site. Ce n'est pas un défaut technique, c'est un problème de formulation : la page doit dire où vit le plan et ce qui l'efface, sinon la promesse devient un piège. Sur Arti, la phrase est affichée en permanence en haut de l'éditeur web.

C'est la première chose à budgéter sur une seconde plateforme : pas le code, le texte qui explique ce que le code fait différemment.

Le poids, et pourquoi il se règle à l'hébergement

Une application compilée pour le navigateur arrive en une fois. Sur Arti, le chargement à froid représente 13,2 Mo bruts, ramenés à 4,7 Mo compressés — et cette compression n'est pas une option d'optimisation, c'est la différence entre une application qui démarre et une page blanche sur une connexion médiocre. L'hébergeur la fournit ou vous la configurez ; dans notre cas, le serveur sert du Brotli, encore plus efficace que gzip.

Deux conséquences de mise en production que l'on découvre rarement avant :

• Rien dans une compilation web n'a de nom unique par version. Le fichier principal porte le même nom à chaque publication. Le mettre en cache pour un an, réflexe habituel des fichiers statiques, garantit qu'un visiteur déjà venu ne recevra jamais la mise à jour. La règle correcte est de revalider : le navigateur garde sa copie et demande simplement si elle est encore bonne.
• Le navigateur exige une isolation d'origine avant d'accorder l'accès au stockage rapide. Sans deux en-têtes précis, l'application ne plante pas franchement : elle se bloque au démarrage avec une erreur qui ressemble exactement à un fichier manquant. C'est le défaut le plus coûteux à diagnostiquer de tout le portage, et il ne se reproduit pas en local.

La remontée de plantages n'existe pas sur le web

Sur mobile et sur Mac, l'outil standard de remontée de plantages est fourni et se branche en quelques lignes. Il n'a pas d'implémentation navigateur, et n'en a jamais eu — ce n'est pas un défaut de configuration, aucun réglage ne le débloque.

Il a donc fallu écrire le nôtre : une route qui reçoit un rapport anonyme, le regroupe par empreinte pour qu'une erreur en boucle ne noie pas le reste, et le conserve quatre-vingt-dix jours. Le rapport ne contient ni identifiant, ni adresse, ni contenu de plan — un identifiant de session aléatoire suffit à distinguer « une personne a déclenché quarante erreurs » de « quarante personnes en ont déclenché une », qui ne se corrigent pas de la même façon.

Compter cette pièce comme acquise parce qu'elle est acquise sur mobile est l'erreur de chiffrage la plus courante sur un projet multiplateforme.

Ce que la version web rapporte

Un lien. C'est tout, et c'est beaucoup : quelqu'un qui hésite peut essayer l'application entière, sans installation, sans compte, depuis la page qui la présente. Pas une démonstration allégée — la même application, avec le même catalogue et le même export.

Pour un produit vendu par téléchargement, cela déplace la question du visiteur de « est-ce que je veux installer ça ? » à « est-ce que ça fait ce dont j'ai besoin ? ». La seconde se répond en deux minutes.

Faut-il le faire sur votre projet ?

Trois cas où la réponse est oui sans hésiter : votre produit s'essaie mieux qu'il ne se décrit ; vos utilisateurs professionnels ne peuvent pas installer de logiciel librement ; ou votre cycle de correction est plus rapide que le rythme de validation d'un magasin d'applications.

Trois cas où c'est non : vous avez besoin d'un accès matériel qu'un navigateur n'accorde pas ; vos fichiers sont trop lourds pour du stockage navigateur ; ou votre équipe ne peut pas tenir deux mises en production distinctes, car c'est bien de cela qu'il s'agit — un seul code, deux publications.

En résumé : comptez la seconde plateforme comme un tiers du travail de la première, pas comme un dixième. Le code se partage vraiment. L'hébergement, la formulation et l'observabilité ne se partagent pas du tout.

Arti est visible sur artiplans.com, et l'éditeur s'essaie directement dans le navigateur depuis cette page.