Guide d'import et migration

Formats, schémas normalisés et chemin de migration vers un backend centralisé.

Principe

Le prototype stocke les données importées localement (IndexedDB). Ce n'est pas une base centralisée. L'interface permet de valider la structure des fichiers avant migration.

Formats acceptés

TypeExtensionRemarques
CSV.csvSéparateur auto-détecté ; encodage UTF-8 recommandé.
Excel.xlsx, .xlsPremière feuille lue ; pas de formules complexes.
GeoJSON.geojson, .jsonFeatureCollection ; Point → lat/lon ; Polygon → périmètre.

Schémas normalisés

Les colonnes minimales attendues par type d'entité :

Site : 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 : id, type, siteId, parcelleId, nom, code, culture, varieteId, espece, statut, plantation, lat, lon, qualite

Observation : id, parcelleId, arbreId, date, type, valeur, auteur, gps, source, statut

Sol : id, campagne, parcelleId, date, profondeur, preleveur, laboratoire, protocole, ph, matiereOrganique, azote, phosphore, potassium, cec, texture, statut

Climat : id, siteId, mois, date, pluie, tmoy, humidite, eto, source, statut

Validation et stockage

  • Validation structurelle uniquement : champs requis, types, coordonnées.
  • Aucune validation scientifique automatique.
  • Stockage local IndexedDB (pas de synchronisation centralisée).
  • Les données importées remplacent les données démo dès qu'un identifiant correspond.

Chemin de migration backend

  1. Activer Lovable Cloud pour obtenir PostgreSQL + auth.
  2. Créer les tables avec RLS et grants.
  3. Remplacer la couche IndexedDB par des appels serveur sécurisés.
  4. Déplacer la validation et la gestion des secrets côté backend.
  5. Conserver le mode démo comme fallback étiqueté.