Fiabilisation Pipeline (J-1)
Billet #70 : Fiabilisation du Pipeline de Données et Alignement de l'Écosystème Projet
Type : Amélioration / Refactorisation
Composant Affecté : code_source_simule/pipeline.py, Tâche Cron, tests/test_pipeline.py, project_docs/
1. Contexte et Objectif Stratégique
Conformément aux objectifs non-fonctionnels du projet, notamment la Fiabilité et l'Automatisation, le pipeline de données quotidien se doit d'être infaillible. L'objectif stratégique est de garantir une collecte de données de marché complète et sans perte, même en cas d'incident technique mineur.
2. Description de l'Approche Initiale (la Vulnérabilité)
L'approche initiale reposait sur une exécution temporelle stricte. Une tâche cron était configurée pour lancer le script pipeline.py chaque soir à 23:59, avec pour mission de récupérer les prix de clôture du jour même (Jour J). Cette architecture était fragile et risquait une perte de données irrécupérable en cas d'échec.
3. Architecture et Logique Implantée
La nouvelle architecture abandonne la dépendance au temps au profit d'une logique métier explicite. Le script, désormais exécuté tôt le matin du Jour J, demande systématiquement à l'API Marketstack les données de la veille (Jour J-1), garantissant la disponibilité et la finalité des données.
4. Justification et Bénéfices
Cette architecture est fondamentalement plus robuste, résiliente aux pannes, et découple la logique métier de l'infrastructure d'exécution, améliorant ainsi la fiabilité et la maintenabilité du système.
5. Audit et Renforcement de la Suite de Tests
La modification de la logique a rendu nécessaire un audit de tests/test_pipeline.py. L'investigation a révélé que les tests existants étaient insuffisants et ne couvraient ni la corruption de données d'entrée, ni la nouvelle logique temporelle. La suite de tests a donc été renforcée avec deux tests de sécurité critiques :
- Un Test "Anti-Corruption" : Pour valider que le pipeline ne plante pas face à un CSV malformé.
- Un Test "Gardien du Temps" : Pour verrouiller le comportement de récupération des données à J-1.
6. Mise à Jour de la Documentation Technique
Un changement de code n'est complet que lorsque sa documentation est alignée. Un audit complet de la documentation (project_docs/docs/features/) a été mené.
- Processus d'Investigation : L'analyse a révélé que les chapitres 1, 2 et 3 contenaient des descriptions obsolètes concernant le timing du pipeline, la fraîcheur des données ("les derniers prix") et les commandes manuelles.
- Cause Racine : La documentation n'était plus synchronisée avec le comportement réel du code, créant une "dette documentaire" dangereuse pour la maintenance future.
- Solution Implantée : L'ensemble de la documentation a été méticuleusement réécrit pour refléter la nouvelle logique J-1, la robustesse accrue face aux erreurs de format de fichier, et les procédures opérationnelles correctes (commandes, configuration du cron).
- Justification : Cette action garantit que la documentation reste une source de vérité fiable, prévenant les erreurs futures et facilitant l'intégration de nouveaux contributeurs.