GGThed 7b9eee4805 feat(db): mesurer la derive du schema, au lieu de la supposer
DB-001. create_all() cree les tables manquantes et ne fait jamais d ALTER.
Une colonne ajoutee a un modele il y a six mois est donc absente de toute
base qui possedait deja la table, et rien ne le dit : l application demarre,
et la premiere requete qui touche cette colonne echoue a l execution. C est
la raison d etre de migrations/add_tryout_coaches.py, ecrit a la main pour
rattraper un cas. Personne ne sait combien il y en a d autres.

app/supporting_scripts/schema_report.py compare le catalogue d une base
vivante aux modeles : tables, colonnes, types, nullabilite, contraintes
d unicite, cles etrangeres, index. En **lecture seule** — il ouvre une
connexion, lit, imprime, sort. Aucun DDL, aucun DML.

Les constats sont classes par ce qu ils coutent, pas par ce qu ils sont :

- BLOCKING : les modeles l attendent, la base ne l a pas. C est la derive ;
- RISK : la base l a, aucun modele ne le decrit. Inoffensif tant que rien
  ne bouge — et **un alembic --autogenerate proposera de le supprimer**,
  avec ses donnees. C est la classe qu on lit en entier ;
- DIFFERENCE : types, nullabilite, contraintes. Chacune demande un humain.

Les types sont compares apres compilation vers le meme dialecte : opposer
String(200) a VARCHAR(200) en chaines aurait signale chaque colonne comme
differente, et un rapport qui crie partout ne se lit plus.

--check-seed-accounts repond a la question de SEC-003 a laquelle le depot
ne peut pas repondre : le compte admin/password seme par clear_db.py
existe-t-il encore, et son mot de passe est-il toujours celui-la.

13 tests le pilotent contre des bases SQLite fabriquees pour diverger d une
facon connue. Le cas qui compte le plus est la base propre : un rapport qui
crie sur une base saine ne sera pas lu, et un rapport qui dit « aucun
ecart » sur une base derivee est pire que pas de rapport — c est un feu
vert pour laisser autogenerate ecrire la difference en DROP.

docs/database-schema.md donne la suite, etape par etape, avec le piege de
DB-002 en toutes lettres : la migration initiale doit decrire la base telle
qu elle est, pas telle que les modeles la decrivent. Generer depuis les
modeles puis estampiller revient a declarer que la derive n existe pas.

Alembic n est pas ajoute aux dependances : rien ne l utilise encore, et une
dependance que rien n utilise est exactement ce que l audit reprochait
ailleurs. Le document dit a quelle etape l ajouter.

530 tests.
2026-08-11 15:00:18 -04:00
2026-08-06 14:46:51 -04:00

Plateforme centralisée de tryouts

Application interne du club e-sport de l'UdeS : inscriptions aux sélections, évaluations, gestion des équipes, disponibilités, contrats, et notifications Discord.

Le site est servi en français, l'anglais reste accessible par le sélecteur de la barre latérale (voir docs/translations.md).


Démarrer

python -m venv .venv
.venv/Scripts/pip install -r requirements.txt -r requirements-dev.txt
cp app/.env.example .env      # puis remplir SECRET_KEY et DATABASE_URL
.venv/Scripts/python run.py   # développement, http://127.0.0.1:5000

SECRET_KEY et DATABASE_URL sont obligatoires : create_app() refuse de démarrer sans eux. DATABASE_URL doit pointer sur PostgreSQL ; le pilote psycopg 3 est nommé automatiquement si l'URL n'en nomme pas.

Production : python wsgi.py (Waitress derrière nginx). Voir docs/deployment.md.

Ce sont les deux seuls points d'entrée.

Vérifier

.venv/Scripts/python -m pytest        # suite complète
.venv/Scripts/python -m ruff check .  # lint
.venv/Scripts/python -m ruff format --check .

Les trois tournent en CI et y sont bloquants.


Ce que fait l'application

  • Comptes et rôles — cinq rôles : président (admin), gérant (manager), coach, joueur (player), recruteur (scout). Le président attribue les rôles.
  • Sélections — organisation des tryouts, trois formats de match (équipe contre équipe, joueur contre joueur, scrim), évaluation des joueurs sur dix critères.
  • Équipes — effectifs de la saison, matchs et entraînements. Le formulaire d'entraînement affiche les disponibilités des joueurs.
  • Disponibilités — créneaux hebdomadaires des joueurs, créneaux réservables des coachs.
  • Notes — un coach écrit des notes d'équipe (visibles par l'équipe) et des notes nominatives (visibles par le joueur concerné).
  • Un-à-un — un joueur demande une séance à son coach ; le coach répond depuis le site ou par une réaction sur le message privé Discord.
  • Contrats — dépôt d'un contrat par le staff, signature par le joueur.

Comment c'est construit

Backend Python 3.12 / Flask, rendu serveur en Jinja2, CSS et JavaScript maison, sans framework front. Base PostgreSQL via SQLAlchemy. Bot Discord (discord.py) dans un fil du même processus que le serveur web.

docs/architecture.md contient les diagrammes (classes, paquets, flux d'une requête).


Sécurité

En place et vérifié par des tests :

  • Limitation de débit sur la connexion (10 requêtes/minute par IP).
  • Cookies de session HttpOnly, SameSite=Lax, Secure, avec expiration effective.
  • CSRF sur tous les formulaires, y compris la déconnexion (en POST).
  • HTTPS forcé en production, HSTS.
  • CSP sans unsafe-inline sur script-src : aucun gestionnaire d'événement en ligne, chaque bloc <script> porte un nonce par requête.
  • Redirections validées (rien ne sort du site).
  • Validation par schémas marshmallow sur les formulaires de compte, avec politique de mot de passe.
  • Autorisation centralisée dans app/permissions.py.
  • Journal d'authentification (logs/auth.log) : connexions, échecs, changements de rôle, suppressions de compte.
  • Téléversements vérifiés par extension et par signature de fichier.

Ce qui n'est pas fait, pour que personne ne s'y fie :

  • Aucune migration de schéma. db.create_all() crée les tables manquantes et ne modifie jamais une table existante : une colonne ajoutée à un modèle est absente de la production.
  • Les secrets de l'historique git ne sont pas révoqués — jeton du bot, mot de passe PostgreSQL, SECRET_KEY.
  • trusted_proxy='*' dans wsgi.py : l'en-tête X-Forwarded-For est accepté de n'importe quelle source, donc la limitation par IP est contournable. À régler avec la topologie réelle du déploiement.
  • L'identité Discord transite encore par un champ caché du formulaire d'inscription : elle n'est pas prouvée par le passage OAuth2.

docs/security-checklist.md détaille la liste avant mise en production.


Intégration Discord

Messages privés au coach lors d'une demande d'un-à-un, aux joueurs à la création d'un match ou d'un entraînement les concernant, et rappel 24 h avant un match. Les réponses se font par réaction sur le message ou depuis le site.

L'état des messages en attente de réponse est dans discord_pending.json, non versionné : c'est de l'état d'exécution, propre à chaque serveur.

Mise en place

Le bot du club existe déjà ; ce qui suit ne concerne qu'une nouvelle installation.

  1. Créer une application sur le portail développeur Discord, puis un bot.
  2. Copier le jeton dans DISCORD_BOT_TOKEN.
  3. Activer Message Content Intent dans les Privileged Gateway Intents. C'est le seul intent privilégié demandé : il sert à lire le motif d'un refus écrit en réponse au message.
  4. Chaque personne doit partager un serveur avec le bot (ou l'avoir en ami) pour recevoir un message privé, et renseigner son identifiant Discord dans son profil (Discord → Paramètres → Avancés → Mode développeur, puis clic droit sur son profil → Copier l'identifiant).

/health indique si le bot tourne et s'il est connecté.

S
Description
No description provided
Readme
2.3 MiB
Languages
Python 67.9%
HTML 27%
CSS 3.5%
JavaScript 1.6%