Architecture
LotoStats sépare le frontend, les traitements de données et la publication. L'application est livrée sous forme de build statique et ne nécessite ni serveur applicatif ni base de données utilisateur pour fonctionner.
Sources de données
- API publiques / archives FDJ
- validation / transformation
Frontend
- React + TypeScript
- calculs statistiques
- PWA
Production
- GitHub / CI
- build Vite
- VPS / Apache / HTTPS
Frontend et application
LotoStats est une SPA mobile-first installable comme PWA. TanStack Query gère les requêtes et le cache des différentes sources. Zod valide les structures reçues avant leur utilisation.
Stack
- React 18
- TypeScript 5.8
- Vite 5
- TanStack Query
- Zod
- Tailwind CSS 3
- shadcn/ui
- Radix UI
- Vitest
- ESLint
- Calcul des fréquences et écarts côté navigateur.
- Filtres selon les jours de tirage.
- Stockage des grilles et préférences dans localStorage.
- Conservation possible d'un snapshot statistique avec une grille.
- Thèmes clair et sombre.
- Manifest, service worker et ressources PWA dédiées.
Données et traitements
Les historiques de tirages proviennent de deux pipelines distincts : l'un interroge une API publique, l'autre prépare les archives FDJ sur le serveur.
Loto
- Opendatasoft
- pagination
- validation Zod
- déduplication / tri
- statistiques dans le navigateur
Les tirages Loto utilisés pour les statistiques proviennent du dataset public resultats-loto-2019-a-aujourd-hui@agrall. Le frontend récupère les pages de données, valide leur structure, déduplique et trie les tirages avant les calculs statistiques. Les données de gains sont fournies séparément sous forme de JSON et validées avant usage.
EuroMillions
- archives FDJ
- Python / Bash
- normalisation
- contrôles
- JSON publié
- frontend LotoStats
Un script Python exécuté sur le VPS télécharge les archives historiques FDJ et produit un JSON directement exploitable par le frontend.
- dates
- colonnes attendues
- 5 numéros
- 2 étoiles
- règles historiques des étoiles
- doublons
- continuité de l'historique
Le fichier est publié après validation et mis à jour automatiquement chaque jour par une tâche planifiée.
À partir des historiques chargés, le frontend calcule notamment les occurrences, fréquences, raretés et écarts depuis la dernière apparition. Les calculs décrivent les tirages passés et ne constituent pas un modèle prédictif. Les données nécessaires aux statistiques et celles nécessaires à l'enrichissement des gains peuvent provenir de sources distinctes et utilisent des caches React Query séparés.
Qualité et cycle de développement
GitHub constitue la source de vérité du code. La CI s'exécute sur les pull requests et sur main.
Cycle
- branche
- pull request
- GitHub Actions — TypeScript, Vitest, ESLint, build
- merge main
Commandes CI
npm ci npm run typecheck npm run test npm run lint npm run build
Assistance au développement
Lovable est utilisé pour certaines phases de prototypage et d'interface. Des outils GPT/Codex sont également utilisés pour des audits, diagnostics et modifications ciblées. Ces outils font partie du processus de développement ; ils ne sont pas intégrés à l'application exécutée par l'utilisateur. Les modifications passent par le même cycle Git, tests et CI avant intégration.
Mise en production
Le déploiement est lancé depuis le poste de développement par un script dédié. Il vérifie l'état Git, produit le build statique, le transfère vers le VPS puis effectue des contrôles HTTP après publication.
Pipeline de publication
- main
- build Vite
- script de déploiement
- SCP / SSH
- VPS
- Apache / HTTPS