QSOlog : un carnet de trafic pour radioamateurs qui se passe de serveur

Les radioamateurs consignent chaque contact - un QSO dans le jargon - dans un carnet de trafic : indicatif de la station contactée, fréquence, mode, report de signal, heure en UTC. Traditionnellement, c'était un cahier sur la table de la station ; aujourd'hui, c'est le plus souvent un logiciel. Avec QSOlog, nous avons construit un tel carnet de trafic en projet open source - avec une décision d'architecture qui le rend intéressant au-delà du hobby : il n'y a pas de serveur.

L'absence de backend est une fonctionnalité

QSOlog tourne entièrement dans le navigateur. Tous les QSO résident dans IndexedDB, via Dexie.js. Pas de compte, pas de connexion, pas de base de données sur un serveur et aucune transmission des données de trafic à des tiers. Trois conséquences agréables :

La confidentialité par l'architecture : des données qui ne quittent jamais l'appareil n'ont pas besoin d'être sécurisées, chiffrées ni encadrées par un contrat de sous-traitance.
Une exploitation sans coûts d'exploitation : l'application est un site statique. GitHub Pages suffit comme hébergement ; il n'y a rien à corriger, à dimensionner ni à surveiller.
Aucun risque de panne : un service qui n'existe pas ne peut pas être arrêté. Le carnet de trafic continue de fonctionner même si le projet cessait un jour d'être maintenu.

Le prix à payer, c'est de la rigueur ailleurs : les données vivent dans le profil du navigateur, les fonctions d'export doivent donc être irréprochables - on y vient.

Le hors-ligne est la norme, pas l'exception

Le trafic radio se fait souvent là où la couverture mobile est faible : au sommet d'une montagne, sous la tente d'un field day, en vacances. Un carnet de trafic qui exige une connexion internet serait optimisé au mauvais endroit. QSOlog est donc construit comme Progressive Web App : après le premier chargement, un service worker (via vite-plugin-pwa) prend le relais, l'application s'installe sur ordinateur comme sur smartphone et démarre sans réseau.

C'est la même rigueur hors-ligne que nous recommandons pour les applications métier internes utilisées sur le terrain : écrire d'abord en local, le réseau est optionnel. Seules les recherches d'indicatifs facultatives via QRZ.com ou HamQTH nécessitent une connexion - et elles sont volontairement conçues comme un plus, pas comme un prérequis.

Les données appartiennent à l'utilisateur

Quand aucun serveur ne sauvegarde les données, l'export doit être irréprochable. QSOlog parle ADIF 3.1.4, le format d'échange établi du monde radioamateur, ainsi que CSV et JSON. L'import valide les données et détecte les doublons, si bien que les carnets existants issus d'autres logiciels se reprennent sans risque. Pour le papier, il y a des rapports PDF en A4 paysage avec statistiques de synthèse.

C'est la même position que nous défendons dans les projets clients : une application n'est terminée que lorsqu'on peut aussi la quitter. Des formats standards en entrée, des formats standards en sortie - pas de verrouillage.

La logique métier entièrement dans le frontend

Sans backend, tout le domaine métier passe dans le frontend, et le radioamateurisme en a beaucoup à offrir :

Locator Maidenhead : à partir de deux carrés de grille, QSOlog calcule la distance et l'azimut du contact.
Détection automatique de bande : la fréquence saisie est associée à la bande amateur correspondante, de 160m à 23cm selon la Région 1 de l'IARU.
RST selon le mode : le report de signal suit le standard adapté au mode d'émission.
Statistiques et carte : Chart.js visualise la répartition par bande et par mode, les séries d'activité et les entités DXCC ; Leaflet trace tous les contacts sur une carte avec regroupement des marqueurs, mode sombre compris.

Techniquement, la pile se compose de Vue 3 avec TypeScript et Vite, de Pinia pour l'état et de Tailwind CSS avec Headless UI pour l'interface. Plusieurs profils d'opérateur et une interface en allemand et en anglais complètent l'ensemble.

Ce que le projet démontre

QSOlog est un projet annexe né d'un vrai besoin personnel - et en même temps un banc d'essai honnête pour une thèse que nous défendons souvent : pour beaucoup d'applications, la web app installable est la voie la plus directe par rapport à une présence en app store, et toutes les applications n'ont pas besoin d'un serveur. Le code est sous licence MIT sur GitHub ; certaines parties ont été écrites avec l'aide d'outils d'AI coding et relues par des humains - le dépôt l'indique en toute transparence. Que vous soyez radioamateur ou simplement curieux de voir une PWA offline-first bien construite : essayez-la, forkez-la, les issues sont bienvenues.