# Base de données du pilotage

Scripts SQL numérotés, sur le modèle de l'espace client : additifs, joués dans
l'ordre, une table `migration` tenant la trace de ce qui est appliqué.

## Sur une base neuve, deux fichiers suffisent

```
000-schema-complet.sql     les 38 tables, les paramètres, les cinq scénarios,
                           les deux postes de rémunération, le compte de départ
004-grille-mission.sql     la grille de mission : 12 + 12 + 11 éléments,
                           leurs livrables et leurs délais
```

**Avant d'importer `000`, remplacer l'adresse du compte de départ** (dernière
section du fichier, `a-renseigner@ecovivo.fr`). Sans acteur, personne ne peut
entrer : la connexion se fait par courrier, et une adresse inconnue ne reçoit
aucun lien.

`000` enregistre déjà `001`, `002` et `003` comme appliquées : ces trois
fichiers ne servent qu'à rattraper une base créée à un lot précédent, et ne
doivent jamais être rejoués sur une base créée par `000`.

## Les fichiers sont produits, pas écrits à la main

| Fichier | Produit par | À relancer quand |
|---|---|---|
| `001` `002` `003` | `outils/generer-migrations.pl` | `000-schema-complet.sql` change |
| `004-grille-mission.sql` | `outils/semer-grille.pl` | `public/assets/js/ecovivo-grille.js` change |

Écrits à la main, les uns et les autres divergeraient du schéma et de la grille
au premier ajout, et la divergence ne se verrait qu'au moment où l'on en a
besoin. `verifier-tout.ps1` relance les deux outils avant chaque envoi.

`outils/verifier-schema.pl` contrôle en plus trois fautes invisibles à la
relecture de `000` : une table créée mais oubliée dans la liste de purge, une
table purgée avant sa parente, une table qui référence une parente pas encore
créée.

## La base du pilotage (OVH, accordée le 8 septembre 2026)

| | |
|---|---|
| Nom de la base | `ecovivscuillerg` |
| Utilisateur | `ecovivscuillerg` |
| Hôte à mettre dans `config.php` | `ecovivscuillerg.mysql.db` |
| Serveur OVH | `mysql604.eu004` |
| Mot de passe | détenu par le dirigeant, saisi directement dans `app/config.php` (jamais versionné) |

L'hôte n'est **pas** `localhost` : sur ce mutualisé, chaque base vit sur un
serveur MySQL dédié.

## Cloisonnement des deux bases

Les deux applications partagent le serveur MySQL d'OVH, jamais la base.

| Base | Contenu | Utilisateur | Ce qu'il peut faire |
|---|---|---|---|
| celle de l'espace client | chantiers, visas, DPGF, situations | celui de l'espace client | tous droits sur sa base, **rien** sur `ecovivscuillerg` |
| `ecovivscuillerg` | CRM, PTF, chiffrage, trésorerie, projection | `ecovivscuillerg` | tous droits sur sa base, **au plus `SELECT`** sur celle de l'espace client |

Une injection SQL sur l'espace client ne peut atteindre aucune donnée
financière : le serveur refuse, le code n'a pas à être irréprochable pour cela.

### Le pont de lecture : à vérifier avant de compter dessus

Le pilotage a besoin de lire, dans la base de l'espace client, l'avancement
d'un chantier (pour rapprocher un jalon de son encaissement) et les entreprises
déjà fichées.

**Sur OVH mutualisé, un `GRANT SELECT` croisé entre deux bases n'est pas
acquis** : chaque base a un seul utilisateur, du même nom, dont les droits sont
bornés à sa propre base, et le compte n'a en général pas le privilège `GRANT`.
À vérifier dans le manager OVH (section base de données) ou en tentant, depuis
phpMyAdmin connecté au compte `ecovivscuillerg` :

```sql
SELECT 1 FROM `<base_espace_client>`.`projet` LIMIT 1;
```

- **Si ça passe** : le pont de lecture fonctionne, renseigner `db_client_*`
  dans `config.php`.
- **Si ça échoue** : les deux bases sont totalement cloisonnées, ce qui est la
  version la plus étanche de la décision. Le pilotage lit alors l'espace client
  par un **point d'entrée HTTP** que l'espace client expose (réponse JSON,
  authentifiée), pas par SQL. Laisser `db_client_nom` vide dans `config.php`.

### Le pont d'écriture : PTF acceptée → chantier

Le sens pilotage vers espace client (une PTF acceptée crée le chantier, ses
missions, son planning, son échéancier) demande une **écriture** dans la base
de l'espace client. `SELECT` seul l'interdit, et le point d'entrée HTTP est ici
le chemin le plus probable : l'espace client reçoit la PTF acceptée et crée
lui-même le chantier, avec ses propres règles. Point non tranché, voir
`../../README.md`.

## Prérequis OVH à confirmer

- Version MySQL alignée sur l'espace client (**8.4**).
- PHP **8.2 ou supérieur** sur le sous-domaine.
- Extension **ZipArchive** (import du CRM Notion, exports comptables).
- Les appels sortants HTTPS vers Microsoft Graph autorisés.