Aller au contenu principal

Exemple

AssoRegistre : visite guidée d'une application de gestion d'association générée

AssoRegistre est un exemple représentatif de ce qu'une génération Blueprint Maker produit pour une association loi 1901 : une application fictive au nom neutre, décrite écran par écran, pas une capture d'app adhérente. La visite part de la description soumise et suit le résultat jusqu'au tableau de bord.

La description d'origine

« Je gère une association sportive. Chaque adhérent a une fiche avec ses coordonnées, une catégorie (jeune, adulte, famille) et la date de validité de son certificat médical. Les cotisations sont annuelles et je dois savoir en permanence qui est à jour. J'organise des événements — entraînements, tournois, assemblée générale — auxquels les adhérents s'inscrivent. Je veux voir combien d'adhérents sont à jour, le montant encaissé sur la saison et les prochains événements. »

Le plan validé avant la génération

Avant d'écrire la moindre ligne, Blueprint Maker traduit cette description en un plan que l'on valide. Pour AssoRegistre, le plan proposé tient sur un écran : quatre entités — Adhérent, Cotisation, Événement, Inscription — et leurs liens : une cotisation appartient à un adhérent, une inscription rattache un adhérent à un événement.

Les statuts déduits du texte apparaissent aussi dans le plan : la cotisation passe par en attente, encaissée, exonérée ; l'événement par à venir, terminé, annulé. Les trois indicateurs demandés (adhérents à jour, montant encaissé sur la saison, prochains événements) figurent noir sur blanc. Si un élément manque ou déborde, on le corrige ici — ce qui est généré est ce qui a été annoncé.

  • Entités : Adhérent, Cotisation, Événement, Inscription
  • Relations : cotisation → adhérent ; inscription → adhérent ; inscription → événement
  • Statuts : en attente / encaissée / exonérée ; à venir / terminé / annulé
  • Indicateurs : adhérents à jour, montant encaissé sur la saison, prochains événements

La navigation : une section par entité

L'application générée s'ouvre sur une barre latérale sobre : Tableau de bord, Adhérents, Cotisations, Événements, Inscriptions. Chaque section mène à une liste — pas un tableur, une vraie liste d'application : champ de recherche en tête, colonnes triables d'un clic, pagination, et un compteur qui indique combien de résultats répondent au filtre en cours.

La liste des adhérents montre le nom, la catégorie, la date de validité du certificat médical et l'état de la cotisation courante. Un filtre par statut et un filtre de période s'ajoutent à la recherche. Ces filtres vivent dans l'adresse de la page : la vue « adhérents dont la cotisation est en attente » se met en favori, ou s'envoie par message au trésorier — il ouvre exactement ce que vous regardiez.

Le bandeau d'échéances : ce qu'il faut traiter cette semaine

C'est la pièce la plus utile pour une association, et elle est posée automatiquement dès qu'une entité porte une date d'échéance. Au-dessus de la liste, l'application affiche un bandeau qui résume l'état en une ligne : combien de certificats médicaux sont expirés, combien arrivent à échéance aujourd'hui, et combien tombent dans les sept jours.

En dessous, les cinq échéances les plus proches sont listées nommément, triées par date, chacune avec un bouton « Traiter » qui ouvre directement la fiche concernée. S'il y en a davantage, le bandeau le dit. Une ligne dont le statut indique qu'elle est réglée sort du bandeau d'elle-même : on ne voit que ce qui reste à faire.

En pratique : en ouvrant l'application avant une réunion de bureau, on voit d'un coup d'œil les certificats à renouveler et les cotisations en attente — sans avoir rien trié, rien filtré, rien calculé de tête.

La fiche adhérent, avec son historique

Cliquer sur un adhérent ouvre sa fiche : coordonnées, catégorie, date de validité du certificat. En dessous vient la partie qui change tout par rapport au tableur : l'historique des cotisations de CET adhérent, en tableau daté — la cotisation de la saison précédente encaissée en septembre, celle de la saison en cours encore en attente — et la liste de ses inscriptions aux événements passés et à venir.

Ce rattachement n'est pas cosmétique : il vient de la base relationnelle générée. Corriger une adresse la corrige partout, et le nombre d'inscrits affiché sur un événement découle des inscriptions, rien n'est recopié à la main.

Les événements en agenda, plutôt qu'en liste

Les événements peuvent être présentés en agenda plutôt qu'en liste, avec les vues jour, semaine et mois. C'est la lecture naturelle d'une saison associative : on voit le week-end de tournoi trois semaines à l'avance, et l'assemblée générale à sa date.

Le formulaire d'inscription est court parce que la structure fait le travail : l'adhérent se choisit dans une liste déroulante (pas de nom retapé à la main, donc pas de doublon), l'événement de même, la date est pré-remplie. À l'enregistrement, la liste des inscriptions, la fiche de l'adhérent et le tableau de bord reflètent la saisie — c'est la même base pour tous les écrans.

Le tableau de bord : les chiffres du pitch, calculés sur la base

Le tableau de bord reprend exactement les indicateurs demandés dans la description : le nombre d'adhérents à jour de cotisation, le montant encaissé sur la saison, les prochains événements avec leur nombre d'inscrits, et une répartition des adhérents par catégorie.

Ces chiffres sont des requêtes sur la base, pas des saisies : chaque cotisation enregistrée les met à jour. Chaque liste s'exporte par ailleurs en CSV — et l'export porte exactement les lignes affichées à l'écran, filtre compris, avec le compte dans le libellé du bouton. De quoi préparer la liste des présents à l'assemblée générale, ou transmettre un état au trésorier.

Ce que l'application ne fait pas, et il vaut mieux le savoir avant

AssoRegistre tient le registre : qui est adhérent, qui est à jour, qui vient à quoi. Elle n'encaisse pas : aucun paiement en ligne, aucun prélèvement, aucun rapprochement bancaire n'est généré. Le montant d'une cotisation se saisit une fois l'encaissement fait ailleurs.

Elle n'émet pas non plus de reçu fiscal de don, ni aucun document réglementaire. Et elle affiche les échéances, elle ne les envoie pas : le bandeau signale à l'ouverture de l'écran ce qui est en retard et ce qui arrive, sans courriel ni SMS automatique à l'adhérent. Ce sont des briques qu'un développeur peut ajouter — le code s'exporte — mais elles ne sortent pas de la génération.

Les données de démonstration : juger sur des écrans pleins

AssoRegistre arrive rempli : plusieurs mois de vie simulée, des adhérents aux noms plausibles répartis dans les trois catégories, des cotisations à tous les stades, des événements passés et à venir avec leurs inscriptions — dont, à dessein, quelques certificats expirés et quelques cotisations en attente, pour voir le bandeau d'échéances fonctionner.

C'est un choix délibéré : on ne juge pas un outil de gestion sur des tables vides. Les données de démonstration s'effacent ensuite pour laisser place aux vraies. L'application vit sur son URL dédiée, et son code source complet s'exporte (ZIP ou push GitHub), du Next.js + Prisma standard.

Le cas d'usage correspondant

La gestion d'association, sans le tableur partagé qui craque

Décrivez votre association, obtenez votre AssoRegistre