Une application web sans serveur : pourquoi PhotoGrid tourne 100 % dans le navigateur

Vous avez une planche de famille à tirer, une série de photos d'identité ou une dizaine de clichés à poser sur une feuille. Vous ouvrez Word, vous redimensionnez à la main, et vous gâchez deux feuilles avant que ça tombe juste. C'est ce problème, que tout le monde a déjà rencontré, qui m'a poussé à construire PhotoGrid : un petit outil à moi pour poser plusieurs photos sur une page, à la bonne taille, du premier coup. Et pour ça, aucun serveur : tout se passe dans votre navigateur.

Le problème : imprimer plusieurs photos sans gâcher la feuille

Posez la question à un moteur de recherche et vous tombez sur des dizaines de tutoriels. Les méthodes ne manquent pas : Word, l'aperçu de Windows, un montage dans Canva, ou un outil qui découpe l'image en morceaux à recoller. Tous fonctionnent à peu près, et tous ont le même défaut : ce que vous voyez à l'écran ne sort pas à la bonne taille. Un logiciel grand public raisonne en pixels, pas en millimètres. Vous lui demandez quatre photos sur une page A4, il vous en met trois et demie, recadre ce qui dépasse, et vous découvrez le résultat une fois la feuille imprimée.

PhotoGrid part de l'autre bout. La page est calculée en millimètres, exactement aux dimensions du format choisi. Vous posez vos photos sur une grille réglable, vous ajustez les colonnes, les lignes, les marges et l'espacement, et l'aperçu correspond au millimètre à ce qui sortira de l'imprimante. Pas de mise à l'échelle surprise au moment d'imprimer.

Le pari : tout faire sans serveur

La plupart des applications web fonctionnent en deux temps. Votre navigateur affiche l'écran, et un serveur, quelque part, fait le vrai travail : vous lui envoyez vos photos, il les traite, il vous renvoie le résultat. C'est le schéma classique, et pour beaucoup de cas c'est le bon. Pour PhotoGrid, j'ai voulu l'inverse : rien ne part nulle part. L'import, le redimensionnement, la composition de la grille et la génération du PDF se font entièrement sur votre appareil.

Pourquoi se priver d'un serveur ? Parce que pour ce produit, ne pas en avoir est un avantage. Vos photos de famille restent chez vous, il n'y a pas de compte à créer, et comme rien ne dépend du réseau, l'application marche même sans connexion. Côté infrastructure, je n'ai aucun stockage de données à héberger ni à sécuriser : il n'y a tout simplement pas de données à perdre.

Et cette promesse, vous n'êtes pas obligé de me croire sur parole. Le code de PhotoGrid est ouvert sur GitHub (licence AGPL), donc n'importe qui peut vérifier qu'aucune image ne part sur un serveur. Beaucoup d'outils d'impression en ligne affirment la même chose ; peu vous donnent les moyens de le contrôler. Sous le capot, ça tient sur quelques briques.

Hors-ligne, installable, et même sur Android

Le mot technique pour ce genre d'application, c'est PWA (progressive web app). En clair : une application web qu'on installe comme une vraie appli, avec son icône sur l'écran d'accueil, et qui continue de fonctionner sans connexion. Pas de passage obligatoire par un store, pas de téléchargement de plusieurs dizaines de mégaoctets : on ouvre une adresse, on installe, c'est prêt.

Pour PhotoGrid, ça repose sur deux mécanismes. Un service worker (géré par une bibliothèque appelée Serwist) garde les fichiers de l'appli en cache, ce qui la rend disponible hors-ligne. Et les photos que vous êtes en train de composer sont rangées dans la mémoire locale du navigateur (IndexedDB), pour que vous les retrouviez en revenant, sans qu'elles soient jamais parties ailleurs.

Comme la même base de code peut aussi être empaquetée, PhotoGrid existe en plus comme application Android, via Capacitor. C'est le même produit et la même logique, avec des mises à jour livrées à chaud plutôt qu'en repassant par un téléchargement complet. Elle arrivera bientôt sur le Play Store ; pour l'instant, elle s'installe en APK depuis GitHub, ou directement comme PWA depuis le navigateur. Un seul code à maintenir, plusieurs façons d'y accéder.

PhotoGrid est un de mes projets personnels. Mais la façon de le construire est exactement ce que j'apporte sur un projet client : partir de votre besoin réel pour choisir l'architecture, plutôt que de plaquer la même grosse machine sur tout. Vous avez un seul interlocuteur du premier échange au déploiement, celui qui conçoit, code et maintient votre outil. Pour le détail de la prestation, voir développeur d'applications métier sur mesure.

Sans serveur : quand c'est le bon choix, et quand il en faut un

Le bon choix dépend entièrement de ce que l'application doit faire. Tout garder sur l'appareil est imbattable pour un usage personnel ; ça devient un frein dès qu'il faut partager ou synchroniser des données entre plusieurs personnes. Voici où passe la frontière.

Pour PhotoGrid, la colonne de gauche l'emporte sur toute la ligne : un usage individuel, des photos personnelles, aucune raison de centraliser quoi que ce soit. À l'inverse, une application d'équipe, un espace client ou un suivi partagé ont besoin d'un serveur : c'est lui qui héberge les données communes et les garde accessibles de partout. Là, s'en passer n'aurait aucun sens.

Ce que PhotoGrid m'a appris

Le serveur n'a pas été le morceau le plus difficile. Le vrai casse-tête, ça a été de caler le rendu au millimètre, pour que l'aperçu à l'écran et la feuille qui sort de l'imprimante coïncident exactement. Le travail utile est souvent là, dans ce genre de détail, plus que dans le choix d'une techno qui brille. Mettre un serveur, une base de données et des comptes sur un outil d'impression perso aurait coûté plus cher, fragilisé vos données et imposé une connexion, sans rien régler. Et monter une appli d'équipe sans serveur serait tout aussi bancal.

Avant « web ou mobile » ou « avec ou sans serveur », la question qui compte reste la même : de quoi votre projet a-t-il vraiment besoin ? Le reste en découle. Si vous voulez vous faire votre propre idée, l'outil est en ligne et son code est ouvert, à essayer comme à inspecter : photogrid.ojicode.fr.