Aller au contenu

Données de marché manquantes sur les titres

Billet #206 : Données de marché manquantes sur les titres
Type : Débogage / Correction de bug / Fiabilité du pipeline
Composants concernés : code_source_simule/pipeline.py, data/tipranks_raw.csv, base de données (titres, historique), Marketstack v2/eod

1. Contexte et Symptômes

Cela faisait quelques jours que l'application n'affichait plus de prix récents dans l'interface. Le pipeline d'import continuait à s'exécuter, mais les données attendues n'apparaissaient pas dans la table historique de la base de données.

L'objectif de cette intervention était d'isoler précisément l'origine du défaut :

  1. appel API (Marketstack),
  2. logique de date d'import,
  3. insertion en base,
  4. affichage dans l'UI.

2. Investigation et Chaîne Causale

J'ai mené l'investigation en séquences courtes avec validation systématique des hypothèses.

2.1 Observations initiales

Cette intervention ayant eu lieu un samedi, le blocage week-end empêchait les imports, ce qui est normal. Après suspension temporaire de ce blocage pour débogage, le pipeline a bien consommé des appels API (quota en hausse). Malgré ces appels, le traitement remontait des prix manquants massifs sur la date testée non ouvrée. La base confirmait l'absence de nouvelles lignes exploitables pour la date concernée.

2.2 Vérifications techniques

La suite des observations initiales a été de procéder à des vérifications techniques ciblées pour isoler chaque maillon de la chaîne. D'abord, j'ai validé l'API sur des titres de référence (KEY, AAL) et des dates ouvrées : les données de clôture existaient bien côté fournisseur. Puis j'ai exécuté un import ciblé en base sur ces mêmes titres, avec insertion réussie et valeurs bien visibles dans l'historique.

Après ce contrôle localisé, j'ai étendu le test à des imports plus larges sur plusieurs dates ouvrées (2026-04-02, 2026-04-07, 2026-04-10, 2026-04-15) ; les imports ont été globalement réussis. Cette phase m'a aussi permis d'identifier un cas fournisseur récurrent (TIXT.XTSE) sans prix sur plusieurs dates. Enfin, j'ai réalisé un contrôle qualité des données et supprimé un doublon ponctuel détecté sur un couple ticker/date.

2.3 Causalité avec l'historique du projet

J'ai corrélé l'incident avec les changements décrits dans un rapport précédent. Cette intervention avait résolu une panne antérieure en introduisant une logique temporelle inadaptée au besoin métier, ce qui explique ce bug.

Le diagnostic final est donc une régression de logique métier sur la date cible d'import, et non une panne API globale ni une rupture de la chaîne d'insertion en base.

3. Actions Réalisées

3.1 Retour à la logique pré-mars

Je suis revenu à la logique qui prévalait avant l'intervention de mars sur le point critique : cibler la veille de marché plutôt que la date courante brute.

3.2 Améliorations ajoutées au-delà du simple rollback

  1. Politique temporelle explicite :
    • blocage le dimanche ;
    • blocage le lundi par défaut ;
    • rattrapage autorisé le lundi matin uniquement après échec enregistré.
  2. Maintien de l'état d'exécution (success/failure) avec raison, pour piloter le rattrapage de manière fiable.
  3. Enregistrement explicite des exceptions inattendues comme échecs exploitables pour la décision suivante.
  4. Validation automatisée des nouveaux cas critiques (rattrapage lundi, blocage lundi sans échec préalable, persistance des échecs inattendus).
  5. Mise à jour de la documentation technique et opérationnelle (chapitres 2 et 3, FR/EN), de la documentation des tests pipeline, des rapports d'exécution et du site de documentation généré.
  6. Alignement de l'approche cron : planification simple côté système, garde-fous métier portés par le code.

4. Résultat Opérationnel

L'état nominal est rétabli et renforcé :

  1. La chaîne API -> pipeline -> base est confirmée fonctionnelle sur jours ouvrés.
  2. Le défaut principal observé côté UI provenait d'un décalage de date de valorisation, pas d'une coupure API globale.
  3. La logique métier est désormais alignée avec l'usage réel : consultation matinale de la veille.
  4. Les règles d'exécution sont explicites, testées et pilotées par un état persistant.
  5. L'environnement est revenu en état stable, avec protections réactivées et robustesse accrue.

L'incident est donc clôturé côté exploitation, avec un niveau de robustesse supérieur à l'état antérieur.

5. Leçons Apprises

  1. Une correction d'incident peut créer une régression différée ; il faut tester les scénarios métier complets, pas uniquement le symptôme initial.
  2. Un pipeline techniquement « vert » n'implique pas une valeur métier livrée : la date de valorisation effective doit être observable.
  3. Le rollback seul était insuffisant : les garde-fous explicites (règles d'exécution + état persistant) sont indispensables.
  4. Documentation, tests et code doivent rester synchronisés ; sinon, la maintenance devient fragile et ambiguë.