Outils de gestion pour deux sociétés

Le problème

Le même gérant dirige deux sociétés. Chaque mois, il doit produire pour sa comptable un récapitulatif par salarié — heures supplémentaires, paniers repas, petits déplacements, absences — qu'il recompose à la main dans un tableur, à partir de documents qui n'ont pas la même forme d'une société à l'autre.

La contrainte qui commande tout le reste n'est pas technique : l'utilisateur est unique, il n'a aucune compétence informatique, et il saisit une fois par mois, depuis deux postes différents selon les moments. Chaque notion qu'on lui demande de comprendre est une occasion d'abandonner l'outil et de revenir au tableur — sans le dire. Un mois d'écart entre deux utilisations, c'est aussi un mois pour tout oublier.

Ce que j'ai construit

Une adresse unique, protégée par un mot de passe, qui ouvre sur les outils de chaque société : un récapitulatif mensuel pour l'une, un calcul d'heures par salarié pour l'autre, alimenté par l'export mensuel des interventions déjà produit par ailleurs.

Côté serveur, un service Node avec Express et une base SQLite, tenu par systemd derrière Nginx. Côté navigateur, des pages HTML autonomes : pas de framework, pas d'étape de build. Le serveur sert chaque outil directement depuis le dossier de sa société, sans copie intermédiaire.

Choix techniques et pourquoi

SQLite plutôt que PostgreSQL. Toute la base tient dans un seul fichier, ce qui rend la sauvegarde et la restauration triviales. Pour un utilisateur, une saisie par mois et quelques centaines de kilo-octets par an, un serveur de base de données serait un composant de plus à maintenir sans le moindre bénéfice.

Aucun framework côté navigateur. Cet outil doit survivre des années sans que personne y touche. Une page HTML autonome n'a pas de dépendances à mettre à jour, pas de build à refaire, et se répare en l'ouvrant.

Un cache local pendant la saisie. Si la connexion tombe au milieu d'un mois de saisie, la page continue d'accepter la frappe et un bandeau dit explicitement que ce n'est pas encore enregistré en ligne. Perdre vingt minutes de saisie à cause d'une coupure suffirait à faire abandonner l'outil.

Un mot de passe partagé, et pas de comptes. Il n'y a qu'une personne. L'empreinte est stockée dans la configuration du serveur, jamais dans le dépôt ; à la connexion, le serveur pose un jeton de session valable un an, si bien qu'il tape son mot de passe deux fois dans sa vie, une par poste. Il n'y a pas de « mot de passe oublié » : il n'existe aucune adresse à qui écrire, et la procédure assumée est qu'il m'appelle. L'URL secrète sans mot de passe a été écartée — il y a des salariés nommés et des arrêts maladie.

La chaîne de sauvegarde

C'est la partie qui distingue un outil livré d'un outil exploité.

Une copie par jour, trente conservées, produites avec la commande prévue pour ça : copier un fichier SQLite à chaud pendant une écriture peut donner une copie corrompue. Chaque copie est relue et vérifiée juste après avoir été écrite — une sauvegarde qu'on n'a jamais su relire n'est pas une sauvegarde.

La sauvegarde sur le serveur couvre les pannes fréquentes — fausse manipulation, corruption, mauvais déploiement — mais pas la perte du serveur lui-même. C'est acceptable tant que les données sont maigres et reconstituables ; ça cesse de l'être le jour de la première saisie réelle. La copie chiffrée hors site est donc inscrite comme condition de mise en service, pas comme une amélioration à prévoir.

Où ça en est

Les deux outils sont déployés, sauvegardés et surveillés, et attendent la validation du gérant sur des données réelles. Le bouton d'export reste dans chaque outil : quoi qu'il arrive à l'infrastructure, il récupère ses données seul.