Bibliothèque — Application web de consultation du fonds documentaire
Application web de consultation de la bibliothèque du FabLab
Contexte de réalisation
Une commande, un interlocuteur, une contrainte de terrain
Cette réalisation s'inscrit dans le Stage #1, du 1er décembre 2025 au 9 janvier 2026, au FabLab (Fabrication Laboratory) Les Portes Logiques à Quimper. Elle m'a été confiée par Pierre, le responsable du lieu, sous la forme d'un CDC (Cahier Des Charges) rédigé sur Framapad : rendre consultable en ligne un inventaire de livres techniques jusque-là géré sur tableur.
Le CDC posait le quoi et une partie du comment : NocoDB comme base de données, DataTables comme composant d'affichage, une URL cible sur lesporteslogiques.net. Ce que j'ai construit, c'est le reste : l'architecture de l'application, la sélection des champs à exposer parmi les 24 colonnes du CSV (Comma-Separated Values), la résolution du problème de pagination de l'API (Application Programming Interface) REST (Representational State Transfer), le choix de Bootstrap 5 parmi les frameworks CSS (Cascading Style Sheets) proposés, et l'identité visuelle — textures extraites de photos du lieu prises sur place.
La contrainte principale était l'absence de backend : les Portes Logiques n'ont pas de développeur permanent, et Pierre devait pouvoir alimenter la base en autonomie. L'architecture choisie — NocoDB cloud comme base, JavaScript côté client pour la consommation de l'API — répond directement à cette contrainte : aucun serveur applicatif à maintenir, aucune compétence technique requise pour ajouter un ouvrage.
Cette posture de développeuse en contexte associatif — comprendre les contraintes humaines autant que techniques, livrer quelque chose d'utilisable sans infrastructure lourde — est ce qui caractérise cette réalisation dans mon portfolio.
Compétences E5 mobilisées
1.1 ✅ Recenser et identifier les ressources numériques
Inventorier les composants du système d'information (matériels, logiciels, données, services) et les documenter pour en assurer la traçabilité et la gestion.
J'ai recensé et structuré le fonds documentaire du FabLab : 262 ouvrages jusqu'alors gérés sur tableur, cartographiés sous forme de champs dans NocoDB — titre, auteurs, ISBN (International Standard Book Number), mots-clés, date d'acquisition. J'ai aussi identifié les ressources de l'API (Application Programming Interface) REST (Representational State Transfer) : URL (Uniform Resource Locator), token d'authentification, endpoints.
1.2 ✅ Exploiter des référentiels, normes et standards
S'appuyer sur des documentations officielles, des normes de qualité ou des standards techniques pour guider ses choix et garantir la conformité des solutions produites.
J'ai exploité deux référentiels : la documentation de l'API REST NocoDB v3 pour comprendre la structure des endpoints et le format de pagination, et le CSV (Comma-Separated Values) d'inventaire fourni par Pierre, qui m'a servi de référentiel métier pour décider quels champs exposer au public et lesquels masquer.
1.3 ⚠️ Mettre en place et vérifier les niveaux d'habilitation
Définir et contrôler qui a accès à quoi : droits, rôles, comptes utilisateurs — de façon à protéger les ressources tout en permettant le travail des personnes autorisées.
J'ai mis en place un token d'authentification pour sécuriser les appels à l'API NocoDB — seuls les clients connaissant ce token peuvent interroger la base. J'ai identifié et documenté explicitement la limite de cette approche : le token étant intégré dans le JavaScript côté client, il est visible à l'inspection du code — une question que j'ai laissée ouverte pour la suite du projet.
1.5 ✅ Gérer des sauvegardes
Mettre en place une stratégie de sauvegarde des données et des configurations, avec une procédure permettant de les restaurer en cas de perte ou de corruption.
J'ai mis en place une sauvegarde à deux niveaux : les données — les 262 ouvrages — exportées depuis NocoDB en plusieurs versions CSV horodatées (v2, v3, semaine51…), et le code source versionné avec des fichiers .backup au fil du développement, destiné à être poussé sur GitHub. En cas de perte de la base NocoDB, les données sont reconstituables et l'application redéployable.
2.1 ✅ Collecter, suivre et orienter des demandes
Recueillir les demandes des utilisateurs, les qualifier, les prioriser et les orienter vers la bonne ressource ou procédure de traitement.
J'ai reçu une demande de Pierre formalisée dans un CDC (Cahier Des Charges) sur Framapad : rendre consultable en ligne un inventaire de 262 ouvrages. J'ai qualifié cette demande en détail — identifier les 13 champs à exposer publiquement parmi les 24 colonnes du CSV, définir les trois sections de l'application, nettoyer le fichier de données — avant de passer à l'implémentation.
2.3 ✅ Traiter des demandes concernant les applications
Diagnostiquer et résoudre des incidents ou des demandes liés aux applications : dysfonctionnement, anomalie, évolution fonctionnelle.
J'ai diagnostiqué et résolu des problèmes techniques réels dans le cadre de cette réalisation applicative. Le principal : l'API NocoDB retourne les enregistrements par lots de 100, ce qui m'a imposé d'écrire une boucle de pagination côté client pour reconstituer l'inventaire complet des 262 ouvrages — un problème non trivial quand on débute sur les API. J'ai créé des fichiers de test dédiés (test-api-nocodb.html, test-count-nocodb.html) pour isoler et valider ce comportement avant de l'intégrer à l'application finale. J'ai également répondu à la demande de Pierre en livrant une application fonctionnelle et testée.
3.1 ✅ Participer à la valorisation de l'image
Contribuer à construire ou améliorer l'image de l'organisation sur le web, en tenant compte de son identité, de sa charte graphique et du cadre juridique applicable.
J'ai créé une identité visuelle ancrée dans le lieu : j'ai photographié les matériaux du FabLab — bois, câbles, murs, bardage — pour en extraire des textures CSS (Cascading Style Sheets) appliquées à l'interface. Cette application rend aussi visible pour la première fois en ligne le fonds documentaire des Portes Logiques, jusque-là confiné à un tableur interne. J'ai ajouté hors CDC un bouton « Confort visuel » — une initiative personnelle d'accessibilité.
3.3 ✅ Participer à l'évolution d'un site Web exploitant les données de l'organisation
Concevoir, modifier ou enrichir un site web en intégrant les données propres à l'organisation, dans le respect de ses besoins et contraintes techniques.
J'ai conçu et livré quatre pages HTML intégrant les données propres à l'organisation : les 262 ouvrages du fonds documentaire des Portes Logiques, jusque-là confinés à un tableur interne. Ces données — titre, auteurs, ISBN (International Standard Book Number), mots-clés, date d'acquisition — sont exposées via l'API REST NocoDB et rendues consultables en ligne pour la première fois. L'application est conçue pour s'intégrer à l'URL cible prévue par le CDC (https://lesporteslogiques.net/bibliotheque) et s'inscrit directement dans la refonte du site de l'association, menée en Stage #2.
4.1 ✅ Analyser les objectifs et les modalités d'organisation d'un projet
Lire et comprendre un cahier des charges, identifier les contraintes, les acteurs et les ressources nécessaires avant de démarrer une réalisation.
Le CDC de Pierre posait le quoi — NocoDB, DataTables, URL cible — j'ai analysé le comment : quels champs exposer parmi les 24 colonnes du CSV, comment gérer la pagination de l'API qui retourne 100 enregistrements par appel, comment structurer les quatre pages. Cette analyse préalable a guidé toutes mes décisions d'implémentation.
4.2 ✅ Planifier les activités
Découper un projet en tâches, les séquencer dans le temps et organiser leur enchaînement pour atteindre les objectifs dans les délais impartis.
J'ai suivi un enchaînement structuré visible dans l'arborescence du projet : phase dev avec essais initiaux, phase prod, fichiers .backup au fil du développement. Le séquençage — analyse du CSV, modélisation dans NocoDB, test de l'API avec curl (Client URL), boucle de pagination, intégration DataTables, mise en forme Bootstrap 5 — est ma façon systématique d'organiser un cycle de développement.
4.3 ✅ Évaluer les indicateurs de suivi d'un projet et analyser les écarts
Mesurer l'avancement réel d'un projet par rapport à ce qui était prévu, identifier les écarts et les causes de blocage, et ajuster si nécessaire.
L'objectif du CDC était de rendre consultable en ligne le fonds documentaire des Portes Logiques, avec intégration prévue à lesporteslogiques.net. En fin de stage, j'ai mesuré l'écart : l'application est livrée et fonctionnelle ✅, mais elle n'est pas encore intégrée au site de l'association. La cause est structurelle : la refonte du site (Grav, Stage #2) n'avait pas encore démarré à la fin du Stage #1. Le livrable — 4 pages HTML avec librairies locales, prêtes à déploiement — a été remis à Pierre avec cette limite explicitement documentée. L'intégration est planifiée dès que le nouveau site sera en production (Stage #3).
5.1 ✅ Réaliser les tests d'intégration et d'acceptation d'un service
Vérifier que les composants d'un service fonctionnent correctement ensemble et que le résultat correspond aux attentes exprimées avant mise en production.
J'ai créé des fichiers de test dédiés et séparés du code de production — test-api-nocodb.html et test-count-nocodb.html — pour valider l'endpoint, le format JSON (JavaScript Object Notation) retourné et le comportement de la pagination avant d'intégrer le tout. J'ai ensuite vérifié l'intégration complète : API → JavaScript → DataTables → affichage navigateur.
5.2 ✅ Déployer un service
Installer, configurer et mettre en production un service dans son environnement réel, de façon opérationnelle et sans interruption du service existant.
L'application a été livrée à Pierre sous forme d'un livrable autonome et déployable : quatre pages HTML, JavaScript, CSS avec toutes les librairies installées localement (sans CDN — Content Delivery Network), conformément au CDC. Pierre dispose de l'ensemble des fichiers nécessaires à l'installation sur le serveur de l'association. Le déploiement effectif sur lesporteslogiques.net est conditionné à la mise en production du nouveau site Grav — chantier du Stage #3. Cet état intermédiaire est assumé et documenté.
5.3 ⚠️ Accompagner les utilisateurs
Former, documenter ou guider les utilisateurs pour qu'ils puissent s'approprier un service et l'utiliser en autonomie.
Pierre est l'administrateur de la base : c'est lui qui saisit et maintient les données dans NocoDB, l'application se contentant de les consommer via l'API. J'ai travaillé avec lui sur la structure des champs et le nettoyage du CSV, ce qui constitue un accompagnement concret à la prise en main de l'outil d'administration.
6.1 ✅ Mettre en place son environnement d'apprentissage personnel
Structurer les outils, méthodes et ressources qui permettent d'apprendre en faisant, de progresser de façon autonome et de capitaliser ses connaissances.
Pour ce projet, j'ai structuré mon apprentissage de façon délibérée : lecture de la documentation NocoDB avant de coder, test de l'API avec curl pour comprendre les réponses brutes, fichiers de test dédiés, puis seulement développement. J'utilise Claude comme outil de réflexion — pas pour écrire à ma place, mais pour challenger mes hypothèses et déboguer la boucle de pagination.
6.3 ✅ Gérer son identité professionnelle
Construire et entretenir une présence numérique cohérente avec son parcours et ses compétences : portfolio, profil LinkedIn, livrables publics.
Cette réalisation est documentée sur mon portfolio praxis-debug.net avec le code source commenté et les choix d'architecture expliqués. Elle montre concrètement ce que je sais faire : consommer une API REST, gérer la pagination côté client, créer une identité visuelle à partir de matériaux photographiés sur place, livrer une application dans un contexte professionnel réel.
6.4 ✅ Développer son projet professionnel
Analyser ses expériences pour identifier ses points forts, ses axes de progression et les compétences à acquérir en vue d'un objectif professionnel.
Ce projet a soulevé des questions que je veux approfondir : la sécurisation des tokens d'authentification, les requêtes HTTP (HyperText Transfer Protocol) sous le capot, les alternatives à jQuery/DataTables en JavaScript natif. C'était mon premier contact avec une architecture orientée données en conditions réelles — il a confirmé mon intérêt pour les questions d'architecture et de séparation des couches.