Détail du travail

Le problème

Les données d'une installation photovoltaïque ne sont pas centralisées :

• Fournisseur d'électricité (Iberdrola)
• Opérateur du système électrique (REE)
• Onduleur de l'installation

Chaque source :

• fournit des fichiers CSV différents,
• avec des structures, champs et formats différents,
• et sans modèle de données commun.

De plus :

• certains CSV contiennent des relevés toutes les 5 minutes, d'autres offrent des agrégations horaires,
• et le frontend a besoin de données cohérentes et comparables, quelle que soit l'origine.

La solution

J'ai conçu une API qui agit comme couche d'intégration, de validation et de normalisation des données énergétiques, isolant le frontend de la complexité et de l'hétérogénéité des sources de données.

Ingestion avancée de CSV

• Prend en charge 4 formats CSV différents provenant de divers fournisseurs.
• Identifie automatiquement le type de fichier et sa structure.
• Transforme chaque source en un modèle de données unifié.

📊 En usage réel :

• Plus de 1 000 fichiers CSV ont été traités
• Provenant de multiples origines et formats
• Avec des chargements complets et satisfaisants en base de données.

Normalisation et agrégation

Les données sont lues, transformées et persistées toujours comme données horaires, indépendamment de la granularité ou de la structure originale du CSV.

Lors du chargement :

• le fichier reçu est analysé,
• l'information redondante fournie par le fournisseur du CSV est filtrée,
• et la donnée horaire est consolidée, qui est celle persistée en base de données.

Cette logique de transformation est implémentée dans la couche de chargement des fichiers, située dans le dossier uploads, en tirant parti des capacités de Python pour le traitement des fichiers et des données.

À partir de la donnée horaire persistée, l'API offre différentes vues selon la requête :

• Données quotidiennes

  On demande année–mois–jour et l'API renvoie 24 valeurs horaires.

• Données mensuelles

  On demande année–mois et l'API renvoie 28, 29, 30 ou 31 valeurs quotidiennes, selon le mois et l'année.

• Données annuelles

  On demande année et l'API renvoie 12 valeurs mensuelles.

L'API et les vues SQL sont prêtes à répondre différemment à une même requête, comme pour les requêtes mensuelles, où le nombre de résultats varie dynamiquement.

Métriques gérées

• consommation de l'installation
• production photovoltaïque
• balance énergétique avec le réseau :
  • énergie achetée
  • énergie exportée

L'architecture est prête à gérer une batterie, même si cette installation n'en a pas :

• balance énergétique avec batterie :
  • énergie stockée
  • énergie consommée

Performance

• utilisation de vues SQL qui accélèrent les agrégations fréquentes,
• les données consolidées sont persistées, évitant des calculs répétés,
• la base de données agit comme source unique de vérité à partir de la donnée horaire.

Sécurité, rôles et contrôle d'accès

L'API est entièrement protégée :

• Authentification via login et JWT
• Gestion des rôles et des permissions

Seuls les utilisateurs avec le rôle administrateur peuvent :

• gérer la base de données
• charger ou restaurer des données
• exécuter des opérations sensibles

La logique de sécurité est clairement séparée de la logique métier.

Sauvegardes et protection des données

Le système inclut des mécanismes explicites de protection des données :

• Export de la base de données en fichiers JSON
• Chargement de fichiers JSON pour restauration ou migration
• Ces fichiers agissent comme copies de sauvegarde des informations traitées

Cela permet :

• protéger les données historiques,
• faciliter les migrations,
• et réduire les risques opérationnels.

Architecture et stack technique

• Langage : Python
• Framework : Flask
• Base de données : MySQL
• ORM : SQLAlchemy
• Migrations : Alembic / Flask-Migrate
• Authentification : Flask-JWT-Extended
• Testing : pytest, pytest-mock

Dépendances gérées via requirements.txt.

Opérations et déploiement

• API déployée sur PythonAnywhere
• Script deploy.sh pour automatiser les déploiements après mise à jour du dépôt
• Système pensé pour un usage réel en production, pas comme une démo

🔗 API en production

🔗 Dépôt GitHub

Ce que démontre ce projet

Ce projet démontre ma capacité à :

• Concevoir des APIs backend orientées données réelles
• Intégrer des sources externes hétérogènes
• Traiter de grands volumes d'information
• Implémenter sécurité, rôles et contrôle d'accès
• Concevoir des systèmes prêts à grandir et évoluer
• Exploiter et maintenir des logiciels en production

Images du projet