1. Pipeline complet — Vue d'ensemble (10 étapes)

Le système fonctionne en 10 étapes enchaînées, du signal physiologique brut jusqu'à la séance synchronisée dans intervals.icu. Chaque étape produit des sorties consommées par l'étape suivante.

2. Distribution d'intensité — Temps en zone

Le système répartit le temps d'entraînement hebdomadaire entre les zones d'intensité selon un modèle pyramidal : beaucoup de Z1/Z2, moins de Z3, peu de Z4, très peu de Z5. La base de calcul est le temps passé dans chaque zone, pas le TSS ni le nombre de séances.

3. Modèle de charge — Banister Impulse-Response

Le système utilise le modèle classique CTL/ATL/TSB (Fitness/Fatigue/Form) avec les constantes de temps standard. Les valeurs de CTL/ATL proviennent directement d'intervals.icu (source de vérité) et ne sont pas recalculées localement.

Formule du budget TSS 10 jours

Le budget maximum de progression est calculé comme suit :

budget_maintien  = CTL × 10
budget_max       = CTL × 10 + ramp_rate × 10 × 5
recommended_tss  = budget_maintien × multiplicateur_readiness

4. Readiness — Modèle multi-signaux

4.1 Baselines et fenêtre 60 jours (NOUVELLE approche SWC)

Le système calcule des baselines individualisées sur une fenêtre de 60 jours glissants pour l'HRV et la FC repos. Cette fenêtre était historiquement de 42 jours, elle a été étendue à 60 jours pour suivre la méthode HRV4Training (Altini) : 60 jours couvrent ~2 mésocycles complets (build + récup), ce qui évite de biaiser la baseline par un seul bloc de surcharge récent.

4.2 Score Couzens (décision quotidienne)

Un score composite 0-100 intègre 5 signaux pour décider GO / ADJUST / REST :

Décision : REST si score <30 ou ≥2 rouges. ADJUST si score <40 ou ≥2 oranges ou 1 rouge. GO sinon.

4.3 Budget de charge dynamique (multiplicateur 0.70-1.15)

Le budget TSS 10 jours est modulé par un multiplicateur calculé à partir de 5 signaux pondérés (tendances multi-jours, pas valeurs ponctuelles) :

Asymétrie volontaire : le multiplicateur peut descendre de 30% (0.70) mais ne monter que de 15% (1.15). Principe de précaution — il est plus risqué de surentraîner que de sous-entraîner.

Labels : ABSORB si mult < 0.85, MAINTAIN si 0.85 ≤ mult ≤ 1.02, PUSH si mult > 1.02.

5. Fast-Track — Ajustements post-séance

Des signaux post-séance déclenchent des ajustements automatiques sans intervention de l'IA. Le système utilise un score à points (≥3 pts = déclenchement) :

6. Découplage aérobie — Gates de progression

La progression d'un step au suivant dans la matrice de surcharge est conditionnée par la stabilité du découplage cardiaque dans la zone cible :

Régression gate Z2 : si le découplage en Z2 remonte au-dessus de 5%, l'athlète est ramené au step 1 (base aérobie) quelle que soit sa progression en Z3/Z4. Phase PEAK : les gates sont désactivées.

7. Taper — Modèle d'affûtage

8. Répartition par sport

9. Caps de volume et durées de séances

10. Modèle énergétique, glycogène & boucle de prescription

10.1 Dépense calorique

Le système utilise les données de puissance quand disponibles :

• Power-based (Assioma Duo vélo, Stryd course) : kcal ≈ watts × time / 1000
• Fallback TSS (natation) : kcal = TSS × 8
• Crossover CHO/fat : partitionnement par intensité (NP/FTP), 15% CHO en Z1 montant linéairement jusqu'à 100% à ratio ≥1.0

10.2 Modèle glycogène séquentiel (server)

Implémentation : modules/energy.py::glycogen_chain. Modèle simple, linéaire, sans cinétique :

MAX = poids_cible × 8 g/kg  (~536g à 67kg)
morning  = prev_evening − 50g (déplétion hépatique nuit)
post_ex  = morning − CHO_burned_pendant_séance
evening  = min(MAX, post_ex + CHO_ingérés_utiles)

10.3 Modèle client-side (J+1 anticipation + resynthèse retardée)

Implémentation : static/app.js::_computeGlyco. Version étendue du modèle server avec trois raffinements :

• BASAL_CHO = 100 g/jour (consommation cérébrale/organes diurne) soustraite des apports avant resynthèse musculaire
• MAX_DAILY_RESYNTH = 98 g/jour (~7 g/h × 14h éveillées, Ivy 1988)
• Délai d'absorption : split 65% immédiat / 35% reporté sur la nuit (dîner → matin suivant)
• J+1 anticipation : si la grosse séance de demain demande un stock matinal ≥ 350g, les apports CHO d'aujourd'hui sont préchargés (affichés augmentés dans la cible du jour courant)

10.4 NOUVEAU — Prescription CHO intra-séance (boucle fermée)

Chaque pill longue (durée ≥ 60 min, sport ∈ {bike, run}) embarque une prescription CHO intra-séance calculée par modules/energy.py::compute_intra_workout_cho — qui délègue lui-même au helper privé _intra_cho_rate_g_per_h(), source unique de vérité partagée avec nutrition_advice(). Ainsi le banner 🍌 du dashboard, le modèle glycogène client, la projection server, et le texte 🍽 synced vers intervals.icu affichent tous exactement la même valeur.

Barème entraînement (pas race simulation)

Limites physiologiques d'absorption

Cap de sécurité : ne pas dépasser 1.1× le CHO réellement brûlé pendant la séance (évite sur-consommation et risque GI).
Absorption effective utilisée dans le modèle glycogène : 85% (Jentjens & Jeukendrup 2006) — c'est la fraction qui impacte effectivement le net_carb_burn.

10.5 Cibles nutritionnelles journalières

Table energy.py::tss_nutrition_target (paliers TSS → kcal/CHO) :

Ajustement restriction : si phase = restriction ET active_tss < 130 → déficit 450 kcal / 110 g CHO.

10.6 NOUVEAU — Boucle de rétroaction glycogène → prescription

La boucle fermée fonctionne en 4 étapes :

1. Forge : chaque pill longue embarque sa prescription CHO intra (§10.4), stockée en base (grid_slots.intra_cho_g, intra_cho_rate)
2. Modèle glycogène client : _computeGlyco lit data-intra-cho de chaque pill et calcule net_carb_burn = brut − intra_absorbé × 0.85. C'est l'équation clé.
3. Projection server : modules/glycogen.py::project_trajectory applique le même calcul côté serveur pour émettre des warnings si le glycogène matinal projeté passe sous les seuils :
   • < 350g (~65% max) → warning orange "vérifier précharge + intra"
   • < 200g (~37% max) → warning rouge critique "séance compromise"
4. Affichage : les warnings apparaissent comme badges rouges directement sur les pills concernées + le bandeau glycogène du calendrier signale la condition (🍌 Valable SI CHO intra pris).

11. Gap analysis — 7 dimensions vs course

Module advisory (modules/gap_analysis.py) qui lit l'état actuel et projette vers la date de course, calcule un score par dimension et génère des recommandations.

Scoring : ratio vs cible, seuils on_track ≥ 92%, behind 82-92%, critical < 82%. Le score global est une moyenne pondérée (CTL 20%, FTP 15%, EF bike 15%, EF run 15%, swim 10%, weight 10%, durabilité 15%).

12. Courbe de puissance / Classification Coggan

Le système analyse la courbe MMP (Mean Maximal Power) de l'athlète et classifie le profil selon les seuils Coggan W/kg par durée clé :

Profil dérivé (ratios 5s/1min/5min/20min) : Sprinter / Puncheur / Rouleur / Endurance / Grimpeur.

Analyse contextuelle Ironman — facteurs clés par ordre d'importance :

1. Durabilité (capacité à soutenir ~72% FTP sur 5-6h)
2. FTP (niveau de seuil individuel, cible ≥3.8 W/kg)
3. Économie (efficience énergétique, EF stable)
4. VO2max (facteur secondaire en IM long)

Race power IM : ~72% FTP comme NP cible sur 5-6h vélo (standard IM age-group).

e-FTP dynamique via Morton CP (depuis 2026-04)

La FTP utilisée dans tout le pipeline (forge, gap analysis, energy, post_session) est lue dynamiquement via modules/athlete_profile.py::get_current_ftp qui interroge l'API intervals.icu (icu_ftp / icu_run_ftp) avec cache 24h et fallback config.py. L'e-FTP intervals.icu est calculée par le modèle CP 3-param de Morton sur un effort max ≥ 600s.

Tests de calibration (macrocycle.json::calibration_tests) : shapes dédiés ftp_test (vélo, 20min max) et ftp_test_run (run, 15min max) à programmer tous les ~28 jours en phase BASE/BUILD pour rafraîchir l'estimation.

13. IF par zone et par sport

14. Structure des séances — Warm-up / Cool-down

15. Dégradation des shapes par readiness

Quand la readiness est ADJUST/REST OU le multiplicateur budget est dégradé, les shapes complexes sont automatiquement dégradées vers des formes plus conservatrices :

16. Sync intervals.icu

Module modules/intervals_sync.py::envoyer_seance_intervals. Envoie chaque pill comme événement workout vers le calendrier intervals.icu.

Slots horaires par défaut

Format payload

{
  "category": "WORKOUT",
  "start_date_local": "YYYY-MM-DDTHH:MM:SS",
  "type": "Ride" | "Run" | "Swim",
  "name": "<pill title>",
  "description": "Target: Power\n\n<pill content avec steps>"
}

Préfixe Target : "Target: Power" (bike/run) ou "Target: Pace" (swim) pour aider le parser natif d'intervals.icu à interpréter les pourcentages comme FTP ou allure.

Préfixes additionnels : 🍽 nutrition advice (cf. §10.5) et 🍌 CHO intra-séance (cf. §10.4) sont prepended au contenu, séparés par une ligne vide du premier header Warmup (syntaxe intervals.icu respectée).

Auto-sync

Debounce 2s, déclenché par drop/updatePill/reforgePillFromServer. État exposé via /api/sync/status et affiché dans <div id="syncStatus">.

17. Limites transversales du système

Bibliographie complète