# Cahier des charges — JeuxVideoTech

## 1. Contexte et objectif

JeuxVideoTech est une application web multi-utilisateurs permettant à chaque compte de gérer sa propre bibliothèque de jeux vidéo et de consoles.

L’objectif est de centraliser l’inventaire des consoles et des jeux possédés, de pouvoir le consulter facilement depuis un navigateur après authentification, et d’enrichir automatiquement les fiches jeux (jaquette, description, date de sortie, etc.) lorsque c’est possible.

---

## 2. Périmètre fonctionnel

### 2.1 Authentification multi-utilisateurs

- Créer un compte (inscription) avec identifiant et mot de passe.
- Se connecter / se déconnecter.
- Accéder à l’application uniquement une fois authentifié (pages protégées).
- Chaque utilisateur ne voit et ne gère que **sa** bibliothèque (consoles et jeux isolés par compte).
- Un rôle `admin` permet de gérer les comptes (lister, activer/désactiver, supprimer) ; un rôle `utilisateur` gère uniquement sa bibliothèque.
- Mot de passe stocké de façon sécurisée (hash, jamais en clair).
- Session serveur (cookie de session) avec durée de vie raisonnable et déconnexion explicite.

### 2.2 Gestion des consoles

- Ajouter, modifier et supprimer une console (données liées à l’utilisateur connecté).
- Enregistrer au minimum : nom, constructeur, année (optionnelle), notes personnelles.
- Consulter la liste des consoles et le détail d’une console.
- Voir les jeux associés à une console.

### 2.3 Gestion des jeux

- Ajouter, modifier et supprimer un jeu (données liées à l’utilisateur connecté).
- Enregistrer au minimum :
  - titre
  - console associée
  - état (possédé, à acheter, prêté, etc.)
  - notes personnelles
- Consulter la liste des jeux (tri, recherche, filtres par console / état).
- Afficher une fiche détail pour chaque jeu.

### 2.4 Enrichissement automatique (souhaité)

Lors de l’ajout ou de la mise à jour d’un jeu, l’application doit pouvoir récupérer automatiquement, via une API tierce (ex. IGDB, RAWG, ou équivalent) :

- jaquette / image de couverture
- description
- date de sortie
- genre(s)
- éditeur / développeur (si disponible)

Le résultat proposé doit pouvoir être validé ou corrigé manuellement avant enregistrement.  
Si l’API est indisponible, la saisie manuelle reste possible.

### 2.5 Consultation

- Accès depuis un navigateur web (desktop en priorité, mobile acceptable).
- Navigation claire entre listes (consoles / jeux) et fiches détail.
- Affichage visuel des jaquettes dans les listes et les fiches.

---

## 3. Hors périmètre (v1)

- Partage social, commentaires, notes communautaires
- Bibliothèques partagées entre plusieurs comptes
- OAuth / connexion via Google, Discord, etc.
- Emulation ou lancement de jeux
- Synchronisation cloud entre plusieurs appareils (hors volume Docker)
- Application mobile native

Ces éléments pourront être étudiés dans une version ultérieure.

---

## 4. Exigences non fonctionnelles

| Critère | Exigence |
|---|---|
| Disponibilité | Consultation via navigateur, déployée dans un conteneur Docker |
| Simplicité | Stack légère, maintenance facile, peu de dépendances |
| Persistance | Données stockées en fichiers JSON (pas de SGBD relationnel en v1) |
| Sécurité | Isolation des données par utilisateur ; mots de passe hashés ; sessions sécurisées |
| Performance | Affichage fluide pour une bibliothèque personnelle (centaines de jeux par compte) |
| Ergonomie | Interface moderne, inspirée de l’univers jeux vidéo |
| Portabilité | Lancement via `docker compose up` (ou équivalent) |

---

## 5. Choix techniques

### 5.1 Architecture

- Application web (frontend + backend léger) servie dans un conteneur Docker.
- Persistance en fichiers JSON sur un volume monté, pour conserver les données hors du conteneur.

### 5.2 Stack proposée

| Couche | Choix | Commentaire |
|---|---|---|
| Backend | PHP | Cohérent avec les habitudes du projet, simple à dockeriser |
| Frontend | HTML / CSS / JS | Interface responsive |
| UI | Bootstrap (ou équivalent léger) + Pictogrammers (MDI) | Composants prêts à l’emploi ; jQuery uniquement si nécessaire |
| Données | Fichiers JSON | Simplicité ; structure claire et versionnable si besoin |
| Conteneur | Docker + Docker Compose | Déploiement reproductible |

> Les librairies exactes (Bootstrap, alternatives plus modernes type Pico / DaisyUI, etc.) pourront être arbitrées en phase de conception UI, tant que l’interface reste moderne et lisible.

### 5.3 Authentification

- Sessions PHP (cookie `HttpOnly`, `SameSite` adapté).
- Hash des mots de passe via `password_hash` / `password_verify` (algo moderne, ex. bcrypt ou argon2).
- Protection CSRF sur les formulaires d’auth et de mutation.
- Un compte administrateur initial pourra être créé au premier démarrage (seed ou variable d’environnement).

### 5.4 API d’enrichissement

- Une seule API source en v1 (à choisir selon licence / clé API / facilité d’usage).
- Clé API fournie via variable d’environnement (jamais commitée).
- Cache local des images / métadonnées pour limiter les appels externes.

---

## 6. Modèle de données (indicatif)

### 6.1 Utilisateur (`utilisateurs.json`)

```json
{
  "id": "uuid-ou-slug",
  "identifiant": "glainey",
  "email": "glainey@planete-online.fr",
  "motDePasseHash": "...",
  "role": "admin|utilisateur",
  "actif": true,
  "createdAt": "ISO-8601",
  "updatedAt": "ISO-8601"
}
```

### 6.2 Console (`consoles.json`)

```json
{
  "id": "uuid-ou-slug",
  "utilisateurId": "id-utilisateur",
  "nom": "PlayStation 2",
  "constructeur": "Sony",
  "annee": 2000,
  "notes": "",
  "createdAt": "ISO-8601",
  "updatedAt": "ISO-8601"
}
```

### 6.3 Jeu (`jeux.json`)

```json
{
  "id": "uuid-ou-slug",
  "utilisateurId": "id-utilisateur",
  "titre": "Shadow of the Colossus",
  "consoleId": "id-console",
  "etat": "possede",
  "jaquette": "chemin-ou-url",
  "description": "",
  "dateSortie": "2005-10-18",
  "genres": ["Action-aventure"],
  "editeur": "",
  "developpeur": "",
  "notes": "",
  "sourceEnrichissement": "api|manuel",
  "createdAt": "ISO-8601",
  "updatedAt": "ISO-8601"
}
```

Les valeurs d’`etat` seront définies en liste fermée (ex. `possede`, `a_acheter`, `prete`, `vendu`).  
Toute requête CRUD sur consoles / jeux doit filtrer strictement par `utilisateurId` de la session courante.

---

## 7. Interface utilisateur

### 7.1 Direction visuelle

- Ambiance « jeux vidéo » : typographie expressive, contrastes marqués, accents néon / rétro-gaming ou HUD moderne (à trancher en maquette).
- Fond avec texture / dégradé / motif discret (pas de fond plat unique).
- Jaquettes comme ancre visuelle principale des listes et fiches.

### 7.2 Écrans prévus (v1)

1. **Connexion** — identifiant + mot de passe.
2. **Inscription** — création de compte.
3. **Accueil** — aperçu rapide (nombre de jeux / consoles, derniers ajouts) de l’utilisateur connecté.
4. **Liste des consoles** — grille ou tableau + actions CRUD.
5. **Détail console** — infos + jeux liés.
6. **Liste des jeux** — recherche, filtres, jaquettes.
7. **Détail / édition jeu** — fiche complète + bouton d’enrichissement API.
8. **Formulaire d’ajout** — saisie manuelle ou assistée par recherche API.
9. **Administration des comptes** (rôle `admin`) — liste des utilisateurs, activation / désactivation.

### 7.3 Accessibilité minimale

- Contrastes lisibles, navigation clavier correcte sur les formulaires, textes alternatifs sur les jaquettes.

---

## 8. Déploiement Docker

- Un service applicatif (PHP + serveur web, ex. Apache ou nginx + php-fpm).
- Volume persistant pour :
  - les fichiers JSON de données
  - les jaquettes téléchargées (si stockées localement)
- Variables d’environnement pour la clé API, le compte admin initial (identifiant / mot de passe), et éventuellement le port exposé.
- Documentation minimale : `README` avec les commandes de démarrage.

Exemple d’usage attendu :

```bash
docker compose up -d
```

Puis accès via `http://localhost:<port>`.

---

## 9. Critères d’acceptation (v1)

- [ ] Je peux créer un compte, me connecter et me déconnecter.
- [ ] Sans session valide, l’accès aux pages métier est refusé (redirection vers la connexion).
- [ ] Deux utilisateurs distincts ont des bibliothèques isolées (pas de fuite de données).
- [ ] Les mots de passe ne sont jamais stockés en clair.
- [ ] Un admin peut lister / activer / désactiver des comptes.
- [ ] Je peux ajouter / modifier / supprimer des consoles et des jeux.
- [ ] Je peux consulter ma bibliothèque depuis un navigateur.
- [ ] Les jeux sont filtrables / recherchables.
- [ ] L’enrichissement automatique propose au moins jaquette + description + date de sortie (si l’API répond).
- [ ] Les données survivent à un redémarrage du conteneur (volume JSON).
- [ ] L’application démarre avec Docker Compose.
- [ ] L’interface est cohérente avec une esthétique jeux vidéo, moderne et utilisable.

---

## 10. Livrables

- Code source de l’application
- Fichiers Docker (`Dockerfile`, `docker-compose.yml`)
- Structure JSON initiale (exemples ou seed vide)
- README d’installation et d’utilisation
- Le présent cahier des charges

---

## 11. Évolutions possibles (post-v1)

- Import / export CSV ou JSON
- Statistiques (jeux par console, années, genres)
- Wishlist dédiée et rappels
- Réinitialisation de mot de passe par e-mail
- OAuth (Google, Discord, etc.)
- Passage à une base SQLite si le volume de données le justifie