# Guide d'import et de migration backend — PAVResearch

> Ce guide s'adresse aux équipes IRAD et aux intégrateurs. Le prototype actuel stocke les données importées localement dans le navigateur (IndexedDB). Ce n'est **pas** une base centralisée.

## Formats de fichiers acceptés

| Type | Extension | Remarques |
|------|-----------|-----------|
| CSV | `.csv` | Séparateur auto-détecté : point-virgule, virgule ou tabulation. Encodage UTF-8 recommandé. |
| Excel | `.xlsx`, `.xls` | Première feuille lue. Pas de formules complexes. |
| GeoJSON | `.geojson`, `.json` | `FeatureCollection`. Point → lat/lon. Polygon → périmètre parcelle. |

## Schémas normalisés

Les fichiers doivent contenir au minimum les colonnes correspondant au schéma choisi :

### Site / station
`id`, `nom`, `region`, `commune`, `zoneAgro`, `bassin`, `altitude`, `pluvio`, `surface`, `lat`, `lon`, `responsable`, `creation`, `qualite`

### Parcelle
`id`, `siteId`, `nom`, `culture`, `surface`, `anneePlantation`, `densite`, `systeme`, `pente`, `ombrage`, `rendement`, `responsable`, `qualite`, `statutSol`, `polygone`

### Ressource (arbre, génotype, variété, unité)
`id`, `type`, `siteId`, `parcelleId`, `nom`, `code`, `culture`, `varieteId`, `espece`, `geniteur`, `sexe`, `origine`, `statut`, `plantation`, `lat`, `lon`, `qualite`

### Observation terrain
`id`, `parcelleId`, `arbreId`, `date`, `type`, `valeur`, `auteur`, `gps`, `source`, `statut`

### Analyse de sol
`id`, `campagne`, `parcelleId`, `date`, `profondeur`, `preleveur`, `laboratoire`, `protocole`, `ph`, `matiereOrganique`, `azote`, `phosphore`, `potassium`, `cec`, `texture`, `commentaire`, `statut`

### Série climatique
`id`, `siteId`, `mois`, `date`, `pluie`, `tmoy`, `humidite`, `eto`, `source`, `statut`

## Détection automatique

Le nom du fichier peut indiquer le type : `sites.csv`, `parcelles.xlsx`, `observations.geojson`, etc. Sinon, l'utilisateur sélectionne le schéma avant le dépôt.

## Mapping des colonnes

Après l'import, l'interface propose un mapping champ source → champ cible. Les colonnes sont reconnues automatiquement par leur nom ou leur libellé. Le mapping peut être corrigé manuellement.

## Validation

Seule une validation structurelle est réalisée :
- champs requis présents,
- types (nombre, date, coordonnées, énumération) respectés,
- identifiants uniques dans le fichier.

**Aucune validation scientifique** (cohérence pluviométrie, qualité du sol, etc.) n'est appliquée automatiquement.

## Stockage local

Les données importées sont stockées dans IndexedDB via le store `PavResearchImport`. Elles :
- restent sur le poste de l'utilisateur,
- ne sont pas synchronisées entre appareils,
- sont utilisées en priorité par rapport aux données de démonstration dès qu'un identifiant correspond.

## Migration vers un backend centralisé

1. **Activer Lovable Cloud** pour obtenir une base PostgreSQL + authentification.
2. **Créer les tables** `sites`, `parcelles`, `ressources`, `observations`, `climat`, `analyses_sol` avec RLS et grants.
3. **Remplacer `import-persistence.ts`** par des appels `createServerFn` qui écrivent dans Supabase.
4. **Déplacer la validation** côté serveur (types, contraintes, triggers).
5. **Conserver le mode démo** comme fallback étiqueté.
6. **Ne jamais exposer** de clés API côté client ; les secrets restent dans les variables d'environnement backend.

## Étape suivante

Ouvrir l'écran **Import & Ingestion** pour tester un fichier d'exemple et vérifier le mapping avant toute migration.