Ce qu'un tableur ne sait pas tenir
La plupart des structures de réemploi tiennent leurs chiffres dans un classeur : un onglet pour les apports, un pour les pesées, un pour la boutique, un pour les bénévoles. Chacun est juste le jour où il est rempli. Le problème n'est pas la saisie, c'est le RAPPROCHEMENT : personne ne peut dire, un mardi de février, combien d'objets sont entrés le mois dernier, combien sont encore en attente de tri, et combien sont ressortis en vente.
Le tonnage détourné de l'enfouissement est la donnée que réclament les financeurs et les collectivités. C'est aussi celle qui se reconstitue le plus mal a posteriori, parce qu'elle est la somme de gestes quotidiens que personne n'a le temps de consolider.
Le flux propre au réemploi
Un objet de ressourcerie a un cycle de vie, pas un niveau de stock. Il est reçu — d'un particulier, d'une déchèterie, d'une collecte —, pesé, orienté vers une famille (mobilier, textile, électroménager, livres), puis trié : réemployable en l'état, à remettre en état, ou à sortir en filière de recyclage. Ce n'est qu'ensuite qu'il devient un article de boutique, avec un prix et une date de mise en rayon.
Ce sont ces états successifs qui font la différence avec un stock marchand : on ne réapprovisionne pas, on reçoit ce qui arrive. Une application qui décrit ce parcours donne l'information que le classeur ne donne pas — le nombre d'objets bloqués à chaque étape, et depuis combien de temps.
- Apports : origine, date, poids, famille d'objets
- Tri : réemploi direct, remise en état, ou sortie en filière
- Boutique : prix, date de mise en rayon, vente
- Bénévoles : créneaux, présences, activité
Comment l'application est produite
Vous écrivez ce que fait votre structure, en français, avec votre vocabulaire — « apport », « pesée », « valorisation », « adhérent ». 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 besoins d'une ressourcerie 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.
- Ce n'est pas un logiciel de caisse certifié : si votre boutique est assujettie à cette obligation, l'encaissement doit rester sur votre système de caisse.
- Aucune connexion à une balance, une douchette code-barres ou un terminal de paiement.
- Aucune télétransmission vers un éco-organisme ou un portail de déclaration : les chiffres sont consultables et exportables, la déclaration reste manuelle.
- Pas de mode hors ligne : un local de tri sans réseau ne permet pas la saisie en direct.
- Les droits sont globaux (administrateur, utilisateur, lecture seule) — pas de permission par site ni par atelier.
Sortir les chiffres quand on vous les demande
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. C'est le format qui compte au moment d'un bilan annuel ou d'un dossier de subvention : un CSV s'ouvre dans un tableur, se recoupe, et se joint à un dossier.
Les listes se filtrent et se trient, et une corbeille permet de restaurer une ligne supprimée par erreur — utile quand la saisie est partagée entre plusieurs bénévoles qui ne manipulent pas l'outil tous les jours.
Entités
- Apports
- Objets
- Familles d'objets
- Ventes
- Bénévoles
- Adhérents
Vues
- Tableau de bord
- Apports reçus
- Objets à trier
- Boutique
- Ventes
- Bénévoles et créneaux
Indicateurs
- Poids total reçu sur la période
- Objets en attente de tri
- Part des objets orientés vers le réemploi
- Recettes de la boutique
Questions fréquentes
Peut-on encaisser les ventes de la boutique avec l'application ?
Non. L'application enregistre une vente comme une donnée de suivi, mais ce n'est pas un logiciel de caisse certifié et elle n'est reliée à aucun terminal de paiement. Si votre structure est soumise à l'obligation de caisse certifiée, l'encaissement doit rester sur votre système existant.
Peut-on peser les apports directement depuis l'application ?
Non, aucune balance ni douchette n'est connectée : les poids se saisissent à la main. Le code étant exportable et standard, un développeur peut ajouter une intégration matérielle, mais elle n'est pas fournie.
L'application produit-elle les chiffres attendus par un financeur ?
Elle produit les chiffres que vous lui faites suivre — poids reçus, objets triés, part orientée vers le réemploi — et les exporte en CSV ou en JSON. Elle ne remplit ni ne transmet aucun formulaire officiel : le report dans un dossier de subvention ou une déclaration reste manuel.
Plusieurs bénévoles peuvent-ils saisir en même temps ?
Oui, l'application est multi-utilisateurs avec trois rôles : administrateur, utilisateur et lecture seule. Ces rôles sont globaux — il n'est pas possible de restreindre un bénévole à un seul atelier ou à un seul site.
Que se passe-t-il si nous voulons changer d'outil plus tard ?
Le projet est du Next.js et du Prisma standard, exportable en ZIP ou poussé sur GitHub, et vos données s'exportent en JSON et en CSV. Il n'y a ni format propriétaire ni dialecte que seul l'éditeur saurait relire : partir ne demande l'autorisation de personne.