Plan de mise en production
Page de maintenance
Cette page sert au pilotage du projet et n'est pas nécessaire pour utiliser le package au quotidien.
Cette page liste les étapes restantes pour utiliser xyt_gps comme package de production sur des projets GPS réels.
État actuel
| Domaine |
État |
| packaging Python |
structure pyproject.toml, dépendances séparées, tests unitaires en place |
| landing |
notebook et helpers disponibles, contrôle des colonnes, suppression des emails, rapport d'alias |
| loading |
transformation complète vers storyline, legs, staypoints, trips, journeys, user_stats |
| qualité |
suivi, participation hebdomadaire, confirmations, valeurs extrêmes, qualité GPS |
| spatial |
fonctions optionnelles pour zones, origine-destination et relation à une aire |
| enrichissements |
CO2, occupation, santé simple |
| indicateurs |
personne-jour, personne-phase, population |
| notebooks prêts |
Notebooks/Package-ready/00 à 05, puis 06_thematic_analyses |
| documentation |
MkDocs avec workflow, API, notebooks, dépendances et migration historique |
Priorité 1 : stabiliser le contrat de données
| Action |
Pourquoi |
figer le schéma expected_gps_schema() |
éviter les adaptations implicites par projet |
| documenter les colonnes obligatoires et optionnelles par table |
rendre les erreurs d'import compréhensibles |
stabiliser public_transport_legs |
décider si la jointure se fait par leg_id, trip_id ou identifiant fournisseur |
préciser le rôle de user_presence |
distinguer calendrier projet, présence attendue et tracking réellement observé |
| valider les phases par utilisateur |
utile si les dates de phases ne sont pas strictement communes à toute l'expérience |
Priorité 2 : sécuriser la reproductibilité
| Action |
Pourquoi |
| créer un test set stable et validé juridiquement |
permettre des tests de bout en bout sans données sensibles |
| ajouter une CI minimale |
lancer pytest, python -m mkdocs build, contrôle notebooks sans outputs |
| versionner les configs d'exemple non sensibles |
rendre les notebooks exécutables sur une machine propre |
| ajouter un changelog |
suivre les changements de schéma et d'indicateurs |
| décider du versionnement sémantique |
préparer les releases internes puis PyPI |
Priorité 3 : simplifier l'API publique
| Action |
Décision proposée |
garder une API courte dans xyt_gps.__all__ |
exposer surtout ProjectConfig, RawGpsData, prepare_mobility_dataset, compute_mobility_indicators, write_*, plot_* |
| déplacer les helpers avancés vers les sous-modules |
garder disponibles mais moins visibles |
documenter les options de prepare_mobility_dataset() |
éviter l'effet boîte noire |
| conserver les alias historiques seulement temporairement |
par exemple compute_mobility_indicators() |
ajouter validate_mobility_dataset_integrity() |
contrôle unique des clés, liens, CRS, volumes |
Priorité 4 : production analytique
| Action |
Pourquoi |
| définir les indicateurs minimaux de production |
éviter une prolifération de métriques peu stables |
| documenter les hypothèses CO2 et santé |
rendre les résultats défendables |
| stabiliser les figures compatibles dashboard |
participation, modes, distances, CO2, santé |
| exporter un dictionnaire des variables final |
faciliter reprise par une autre personne |
| préparer des exports dashboard |
tables longues, clés stables, formats Parquet/CSV |
Priorité 5 : publication
| Étape |
Condition |
release interne 0.1.0 |
chaîne préparation/indicateurs validée sur test set et anonymized |
| publication GitHub |
dépôt nettoyé, aucune donnée sensible, notebooks sans outputs |
| publication PyPI |
seulement après stabilisation MVP et choix clair de licence |
| documentation publique |
vérifier les mentions de financement, licence, citation et limites |
Critères de passage en production
Le package peut être considéré prêt pour un premier usage de production si :
pytest passe sans erreur.python -m mkdocs build --strict passe.- Les notebooks
notebooks de préparation et notebooks indicateurs s'exécutent sur le test set.
- Les notebooks
notebooks de préparation et notebooks indicateurs s'exécutent sur les données anonymisées.
- Les exports
Data/Output/2-transformed-data, Data/Output/3-enriched-data et Data/Output/4-clean-data contiennent les clés attendues.
- Les liens
legs -> trips -> journeys ne contiennent pas de références invalides.
- Les pertes de données entre landing, loading et indicateurs sont expliquées.
- Aucun fichier
Data/, output HTML, notebook avec sortie ou donnée sensible n'est staged dans git.