Documentation
Club'O'Clock est une application web installable (PWA) de gestion du planning d'entraînement, pensée pour un club sportif associatif de 50 à 150 adhérents administré par des bénévoles.
Chaque club installe sa propre instance : ses données restent chez lui, et il n'existe aucun compte central. C'est le principe qui structure aussi cette documentation — elle s'adresse à toi si tu vas héberger, exploiter et faire vivre l'application pour ton club.
Par où commencer
| Tu veux… | Lire |
|---|---|
| Voir l'application sans rien installer | La démo publique, ou l'application en images |
| Installer une instance pour ton club | Installation & déploiement |
| Explorer le jeu de démonstration | Comptes de démonstration |
| Comprendre ce que fait le produit, et ce qu'il ne fait pas | Spécification produit |
| Comprendre les choix techniques et ce qu'ils coûtent | Cadrage technique |
| Recetter ton instance avant l'ouverture aux adhérents | Plan de tests — membres |
| Contribuer au projet | Guide de contribution |
| Consigner une friction rencontrée en exploitation | Retours terrain |
| Monter un poste de développement sans rien installer | Poste de développement en conteneurs |
Les documents
Démarrer
- Installation & déploiement — du poste de développement à la production. Prérequis, configuration (email, OAuth, notifications push), premier démarrage, déploiement sur mutualisé ou sur VPS, maintenance et dépannage.
- Comptes de démonstration — le jeu de données du club fictif « TEAM44 » : qui est qui, quels cas chaque compte illustre, et la semaine type seedée.
- L'application en images — treize écrans commentés, côté adhérent, coach et bureau.
Comprendre
- Spécification produit — la source de vérité fonctionnelle. Rôles, cycle de vie des comptes mineurs, quotas, liste d'attente, encadrement, notifications, traçabilité. Précise aussi ce qui est hors périmètre, et pourquoi.
- Cadrage technique — les décisions techniques et leurs contreparties assumées : pourquoi un monolithe, pourquoi pas de SPA, ce que l'hébergement mutualisé impose.
Recetter
- Plan de tests — membres — parcours de recette entièrement en interface, sans ligne de commande. Destiné aux testeurs du club.
- Plan de tests — technique — la même recette côté organisateur, avec accès aux journaux, aux commandes Artisan et à la base.
Contribuer
- Guide de contribution — porte de qualité, conventions, périmètre.
- Retours terrain — le carnet des frictions révélées par l'exploitation réelle, déposées au fil de l'eau. Rien n'y est arbitré : c'est la matière première de la prochaine réflexion de périmètre, pas une source de vérité.
- Poste de développement en conteneurs — faire tourner l'application, la porte de qualité et les tests navigateur sans installer PHP, MySQL ni les navigateurs sur sa machine. Outil de poste uniquement : la cible de déploiement reste le mutualisé sans Docker.
- Politique de sécurité — signaler une vulnérabilité.
- Journal des versions — ce qui change à chaque version.
Bon à savoir
Le projet est en français — code, commentaires, interface et documentation. Ce n'est pas un oubli d'internationalisation : c'est un choix assumé pour la version 1.
L'administration est conçue pour le bureau, pas pour le téléphone. L'application est majoritairement consultée au mobile par les adhérents, mais les écrans d'administration supposent un grand écran.
Aucune donnée sensible n'est stockée : ni numéro de téléphone, ni certificat médical, ni numéro de licence fédérale. C'est une contrainte de conception, pas un réglage.
Une question sans réponse dans ces pages ? Les discussions GitHub sont ouvertes. Merci de n'y faire figurer aucune donnée réelle d'adhérent.