MaBibli

Gestion de bibliothèque personnelle, auto-hébergée, pensée pour un foyer. Catalogue, prêts, scan de code-barres, consultation hors-ligne.

• Catalogue des livres physiques et des ebooks — fiches uniquement, aucun fichier n'est hébergé. Revues et séries ont leurs propres fiches.
• Prêts — à qui, depuis quand, et l'historique complet.
• Scan ISBN au code-barres depuis le téléphone, ou saisie manuelle, avec pré-remplissage du titre, de l'auteur, de l'éditeur et de la couverture.
• Statuts de lecture personnels — chacun sa progression, sur une collection commune.
• Liste d'envies personnelle, exportable en .txt et .csv.
• Consultation hors-ligne — PWA installable ; la bibliothèque reste consultable et cherchable sans réseau.

Les métadonnées viennent de la BnF puis d'OpenLibrary, deux sources libres et sans clé d'API. Aucune dépendance à Google Books.

Documentation

Document	Répond à	Pour qui
docs/installer.md	Comment je l'héberge ?	qui installe, sur YunoHost ou ailleurs
docs/publier-une-version.md	Comment je sors une version ?	qui maintient le projet
docs/architecture.md	Pourquoi le code est ainsi ?	qui veut comprendre ou contribuer
mabibli_ynh/doc/ADMIN.md	Où sont les données, qui a accès ?	l'administrateur, après installation

CLAUDE.md porte le contexte de travail : le périmètre de la V1, les invariants à ne pas casser, et les pistes non actées qui restent ouvertes.

En bref

Trois projets .NET, un seul processus en production : le client Blazor WebAssembly est compilé en fichiers statiques que l'API sert elle-même.

MaBibli.Client  ─┐
MaBibli.Shared  ─┼──►  dotnet publish MaBibli.Api  ──►  un service systemd
MaBibli.Api     ─┘         (self-contained)             sur 127.0.0.1

Backend	C# / ASP.NET Core, .NET 10
Frontend	Blazor WebAssembly, en PWA
Base	SQLite + EF Core
Scan	zbar compilé en WebAssembly (LGPL-2.1)
Authentification	SSO YunoHost, via les en-têtes SSOwat — pas d'auth propre
Hébergement	YunoHost, installation native (sans Docker)

Deux contraintes ne se négocient pas, et toutes deux portent sur le serveur : HTTPS (sans quoi le scan caméra ne s'ouvre jamais) et un domaine entier, pas un sous-chemin. Le pourquoi est dans docs/architecture.md.

L'architecture, elle, n'en est plus une : amd64 et arm64 sont publiées à chaque version, et YunoHost choisit la bonne. ⚠️ L'architecture de la machine qui compile est indifférente de son côté — le publish est croisé, et le SDK télécharge le runtime pack de la cible.

Démarrer

dotnet build && dotnet test

dotnet run --project MaBibli.Api

L'API sert aussi le client compilé : une seule commande suffit.

L'URL du dépôt

La documentation porte une URL de démonstration, forge.example.org. Deux valeurs seulement portent la vraie : depot_code, en tête de mabibli_ynh/build/publier.sh, qui commande toutes les URL dérivées, et amd64.url dans manifest.toml, que publier.sh réécrit à chaque publication et qui ne se change jamais à la main.

Pour tirer de ce dépôt une copie publique destinée à des tiers, la marche à suivre est dans docs/publier-une-version.md.

Licence

AGPL v3 — voir LICENSE. L'AGPL attend que les utilisateurs d'un service en réseau puissent en obtenir la source : le lien vers le dépôt affiché dans la page « À propos » de l'application n'est pas un ornement.