Une application qui sait quel exemplaire est sorti, et depuis quand

Le retard n'est écrit nulle part

La plupart des petites bibliothèques tiennent leurs prêts dans un cahier ou un classeur : une ligne par sortie, une date, un nom. C'est parfaitement juste au moment où on l'écrit. Le problème arrive après : un prêt n'est pas une donnée qui reste vraie, c'est un état qui change tout seul. Personne ne repasse sur la ligne le jour où le retour était prévu — le retard existe, et il n'est écrit nulle part.

Conséquence pratique : la liste des livres en retard n'existe que si quelqu'un la reconstitue à la main, en relisant des semaines de lignes une par une, avec un calendrier à côté. C'est un travail que personne n'a le temps de faire, donc il n'est fait qu'une ou deux fois par an, quand un ouvrage manque à l'appel.

Une application ne relit rien : elle compare une date prévue à la date du jour, et l'écran des retards se remplit tout seul. Ce n'est pas une fonctionnalité spectaculaire, c'est simplement le calcul que le cahier ne peut pas faire.

L'ouvrage et l'exemplaire ne sont pas la même chose

C'est la distinction qui décide de la forme de l'application, et c'est celle que les tableurs de bibliothèque manquent presque toujours : un ouvrage est une référence — un titre, un auteur, un ISBN, une catégorie — tandis qu'un exemplaire est un objet physique, avec sa cote, son état, et son historique propre. Une bibliothèque possède souvent trois copies du même roman ; deux sont dehors, une est sur l'étagère.

Tant que les deux sont confondus dans une même ligne, on ne peut ni prêter deux copies en même temps, ni dire laquelle est abîmée, ni savoir si le titre est réellement disponible. En les séparant, chaque question redevient simple : le prêt porte sur un exemplaire, la réservation porte sur l'ouvrage, et la disponibilité se déduit des deux.

Vous décrivez cette organisation avec vos mots, et le plan qui vous est présenté avant construction montre comment elle a été comprise. S'il confond les deux, vous le corrigez à ce moment-là — pas après.

• Ouvrages : titre, auteur, ISBN, catégorie, année
• Exemplaires : cote, état, date d'entrée, ouvrage rattaché
• Prêts : exemplaire, adhérent, date de sortie, retour prévu, retour effectif
• Adhérents : coordonnées, date d'adhésion, cotisation
• Permanences : créneaux, bénévoles présents

Comment l'application est produite

Vous écrivez ce que fait votre bibliothèque, en français, avec votre vocabulaire — « cote », « adhérent », « permanence », « désherbage ». Un plan vous est présenté avant toute construction : les entités retenues, leurs champs, les écrans, les indicateurs. Vous le corrigez tant qu'il ne correspond pas à votre organisation ; rien n'est construit avant votre validation.

L'application produite est un projet Next.js et Prisma standard. Vous pouvez la récupérer en archive ZIP ou la pousser sur GitHub : le code vous appartient, et n'importe quel développeur sait le reprendre. Trois niveaux de génération existent (Sketch, Craft, Masterpiece) selon que vous voulez éprouver une idée ou obtenir une application aboutie.

Ce que l'application n'est PAS

Cette page décrit un outil de suivi interne. Plusieurs attentes légitimes d'une bibliothèque sortent de ce que le produit sait faire, et il vaut mieux le savoir avant de commencer qu'après :

Aucune de ces limites n'est définitive au sens du code — le projet est exportable et un développeur peut l'étendre — mais aucune n'est fournie telle quelle.

• Le catalogue ne se remplit pas tout seul à partir d'un ISBN : aucune base bibliographique externe n'est interrogée, le titre et l'auteur se saisissent à la main. Le champ ISBN sert d'identifiant et de critère de recherche, pas de clé d'import.
• Aucune lecture de code-barres ni de puce RFID : la sortie et le retour se pointent à l'écran.
• Aucune relance automatique par e-mail ou par SMS : les retards s'affichent dans l'application, prévenir l'adhérent reste un geste humain.
• Pas de portail public ni de compte lecteur : un adhérent à qui vous donnez un accès en lecture seule voit toute l'application, pas uniquement ses propres emprunts.
• Pas de mode hors ligne : une permanence sans réseau ne permet pas la saisie en direct.
• Les droits sont globaux (administrateur, utilisateur, lecture seule) — pas de permission par section ni par antenne.

Ce que vous récupérez, et quand vous voulez

Les données saisies restent les vôtres et se récupèrent depuis l'écran Paramètres, en JSON ou en CSV, jeu de données par jeu de données. Un catalogue exporté en CSV s'ouvre dans un tableur, se trie, s'imprime pour un inventaire, et se joint à un rapport d'activité ou à un dossier de subvention.

Les listes se filtrent et se trient, et une corbeille permet de restaurer une ligne supprimée par erreur — utile quand la saisie tourne entre plusieurs bénévoles qui ne prennent la permanence qu'une fois par mois.