# Backend igf.bi — Node.js + MySQL

Portage du backend Django/PostgreSQL vers Node.js (Express + Sequelize)
et MySQL, pour un hébergement qui ne supporte que Node/MySQL.

**Le frontend Next.js n'a besoin d'aucune modification** : toutes les
routes, les formats de réponse, les filtres (`?is_featured=true`,
`?role_type=...`) et l'en-tête `Accept-Language` pour la langue sont
identiques à l'API Django d'origine.

## Ce qui a changé par rapport à la version Django

| Django/PostgreSQL | Node/MySQL |
|---|---|
| Django REST Framework | Express |
| Modèles Django + django-modeltranslation | Sequelize, colonnes `_fr`/`_en` explicites |
| Admin Django | Interface d'admin maison (`/admin`, Express + EJS) |
| pgvector (recherche vectorielle) | Colonne JSON + similarité cosinus calculée en Node (voir `src/services/chatbotService.js`) |
| `python manage.py migrate` | `npm run db:sync` |
| `python manage.py seed_content` | `npm run db:seed` |
| `python manage.py index_content` | `npm run chatbot:index` |
| SMTP via `django.core.mail` | Nodemailer |
| SDK Python `google-genai` | SDK Node officiel `@google/genai` |

## Mise en route

```bash
npm install
cp .env.example .env
# éditer .env : identifiants MySQL, ADMIN_EMAIL/ADMIN_PASSWORD, SMTP, etc.

# Créer les tables dans MySQL
npm run db:sync

# (optionnel) Insérer du contenu d'exemple FR/EN
npm run db:seed

# Démarrer le serveur
npm run dev      # avec rechargement automatique
# ou
npm start
```

Le serveur démarre par défaut sur `http://localhost:8000` — c'est-à-dire
la même URL que Django, aucune variable d'environnement à changer côté
frontend (`NEXT_PUBLIC_API_URL`).

## Base de données MySQL

Créez la base et l'utilisateur avant `npm run db:sync` :

```sql
CREATE DATABASE igf_bi CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'igf_bi'@'%' IDENTIFIED BY 'votre-mot-de-passe';
GRANT ALL PRIVILEGES ON igf_bi.* TO 'igf_bi'@'%';
FLUSH PRIVILEGES;
```

`npm run db:sync` utilise `sequelize.sync({ alter: true })`, pratique
pour démarrer rapidement. Une fois en production avec de vraies données,
il est plus sûr de passer à de véritables migrations Sequelize
(`sequelize-cli`) plutôt que de laisser `alter: true` modifier le schéma
automatiquement à chaque déploiement.

## Gestion de contenu (remplace l'admin Django)

Interface sur `/admin`, authentification par `ADMIN_EMAIL`/`ADMIN_PASSWORD`
(voir `.env`). Tous les modèles y sont : articles, événements,
partenaires, FAQ, base de connaissances du chatbot, etc., avec upload
d'images directement dans les formulaires.

C'est une interface maison (Express + EJS), volontairement simple —
un seul écran liste/formulaire générique piloté par
`src/admin/resources.js`, plutôt qu'une dépendance tierce (type AdminJS)
dont je n'ai pas pu vérifier la compatibilité exacte des versions dans
cet environnement sans accès réseau à npm. Résultat : moins de
fonctionnalités automatiques (pas de glisser-déposer pour réordonner,
pas de recherche/filtre intégrés), mais uniquement des briques stables
et bien connues (Express, express-session, multer), donc plus fiable
sans avoir pu tester une installation réelle.

Le mot de passe admin est comparé directement à `ADMIN_PASSWORD` (pas
de hachage) — c'est suffisant pour un compte unique protégé par un mot
de passe fort, mais si plusieurs comptes admin sont nécessaires un jour,
il faudra ajouter une vraie table `AdminUser` avec mots de passe
hachés (bcrypt).

Pour ajouter un champ à un formulaire existant ou une nouvelle
ressource : tout se passe dans `src/admin/resources.js`, pas besoin de
toucher aux vues.

## Chatbot

Désactivé par défaut (`ENABLE_CHATBOT=false`), comme côté Django. Pour
l'activer : renseignez `GEMINI_API_KEY` et passez `ENABLE_CHATBOT=true`,
puis indexez le contenu :

```bash
npm run chatbot:index
```

Le chatbot répond toujours, même sans clé API ou en cas de panne Gemini
(repli sur une recherche par mots-clés 100% locale, puis sur une réponse
extractive directement tirée de la base de connaissances) — même
garantie de disponibilité que la version Django.

## Fichiers médias

Les images/documents uploadés sont servis depuis `/media/` (dossier
`media/` à la racine du projet), comme `MEDIA_URL` côté Django. Pensez à
sauvegarder ce dossier en production (ou à le brancher sur un stockage
objet si l'hébergement le permet).

## Migrer les données existantes depuis PostgreSQL

Ce projet part d'un schéma neuf. Si vous avez déjà du contenu réel dans
la base PostgreSQL actuelle qu'il faut récupérer (pas juste le contenu
d'exemple du seed), dites-le-moi : j'écrirai un script d'export/import
dédié plutôt que de vous laisser ressaisir le contenu à la main.
