Portfolio Construction & Optimisation

Pourquoi la construction de portefeuille est le vrai edge

La majorité des traders algorithmiques passent 90% de leur temps sur les signaux alpha et 10% sur la construction de portefeuille. C'est une erreur fondamentale. Un excellent allocateur avec des signaux moyens bat systématiquement un mauvais allocateur avec d'excellents signaux. La raison est mathématique : l'alpha d'un signal individuel décroît avec le crowding, mais l'alpha de la construction de portefeuille est structurel et durable.

Le problème de Markowitz et pourquoi on ne l'utilise pas

L'optimisation Mean-Variance de Markowitz est un amplificateur d'erreurs d'estimation. Avec N = 500 actifs, la matrice de covariance a N(N+1)/2 = 125 250 paramètres à estimer. Toute erreur d'estimation est amplifiée par l'inversion de la matrice, produisant des poids extrêmes et instables. En pratique :

Notre stack utilise Kelly fractionnel pour le sizing individuel et HRP pour la diversification inter-stratégies. Ce combo est le sweet spot entre performance et robustesse.

Kelly Criterion — La formule qui maximise la croissance

Le critère de Kelly donne la fraction optimale de capital à risquer sur chaque trade pour maximiser le taux de croissance géométrique du portefeuille. C'est le seul critère mathématiquement optimal pour la croissance long-terme.

Le problème du Full Kelly — Pourquoi on utilise le Half-Kelly

Le Full Kelly maximise la croissance espérée mais génère des drawdowns insoutenables. En pratique, les rendements ne sont pas normaux (queues épaisses) et nos estimations de μ et σ sont bruitées. La solution standard est le Kelly fractionnel :

Le Half-Kelly est notre choix car il maintient 75% de la croissance optimale tout en limitant le drawdown max théorique à ~25%, exactement notre contrainte.

Implémentation avec Claude Code

claude -p "Implémente une classe KellyPositionSizer dans strategies/position_sizing.py :

class KellyPositionSizer:
    def __init__(self, kelly_fraction: float = 0.5,
                 lookback: int = 252,
                 min_trades_required: int = 30,
                 max_position_pct: float = 0.10,
                 min_position_pct: float = 0.005):
        '''
        kelly_fraction: fraction du Kelly optimal (0.5 = Half Kelly)
        lookback: jours de trades historiques pour estimer μ et σ
        min_trades_required: trades minimum pour estimation fiable
        max_position_pct: cap absolu par position (10% du portefeuille)
        min_position_pct: plancher (0.5%) — en dessous, pas de position
        '''

    def compute_kelly(self, strategy_returns: pd.Series) -> float:
        '''Calcule f* = μ/σ² × kelly_fraction, avec shrinkage bayésien.

        Steps:
        1. Calculer μ et σ² sur la fenêtre lookback
        2. Appliquer shrinkage bayésien: μ_shrunk = (n*μ + prior_n*prior_μ)/(n+prior_n)
           avec prior_μ = 0 (sceptique) et prior_n = 50
        3. kelly_raw = μ_shrunk / σ²_shrunk
        4. kelly_adj = kelly_raw × self.kelly_fraction
        5. Clipper à [min_position_pct, max_position_pct]
        '''

    def compute_portfolio_weights(self, strategy_signals: dict[str, float],
                                   strategy_returns: dict[str, pd.Series],
                                   current_regime: str) -> dict[str, float]:
        '''Calcule les poids finaux pour chaque stratégie.

        Pour chaque stratégie active:
        1. kelly_i = self.compute_kelly(strategy_returns[name])
        2. Ajuster selon le régime: si Risk-Off, réduire de 40%
        3. Normaliser pour que sum(weights) <= 0.95 (5% cash minimum)
        4. Retourner {strategy_name: weight}
        '''
"

Le shrinkage bayésien — L'astuce critique

Le Kelly standard surestime systématiquement le sizing optimal car il prend les rendements historiques au pied de la lettre. Le shrinkage bayésien tire les estimations vers un prior sceptique (μ = 0), ce qui :

• Réduit le sizing pour les stratégies avec peu d'historique (protection contre l'overfitting)
• Donne plus de poids aux stratégies avec un long track record fiable
• Converge vers le Kelly classique quand N → ∞

HRP — L'alternative moderne à Markowitz

La Hierarchical Risk Parity (Lopez de Prado, 2016) utilise la théorie des graphes et le clustering hiérarchique pour construire un portefeuille diversifié sans inverser la matrice de covariance. C'est un avantage décisif car l'inversion amplifie les erreurs d'estimation.

Algorithme HRP en 3 étapes

Implémentation

claude -p "Implémente HRP dans portfolio/hrp.py en utilisant scipy et numpy :

import numpy as np
import pandas as pd
from scipy.cluster.hierarchy import linkage, leaves_list
from scipy.spatial.distance import squareform

class HierarchicalRiskParity:
    def __init__(self, cov_lookback: int = 252,
                 linkage_method: str = 'single',
                 min_weight: float = 0.02,
                 max_weight: float = 0.25):
        '''
        cov_lookback: jours pour estimation de la covariance
        linkage_method: 'single' (standard HRP) ou 'ward' (clusters plus équilibrés)
        '''

    def _correlation_distance(self, corr: np.ndarray) -> np.ndarray:
        '''d_ij = sqrt(0.5 * (1 - rho_ij))'''

    def _quasi_diagonalize(self, link: np.ndarray) -> list[int]:
        '''Leaf ordering du dendrogramme'''

    def _recursive_bisection(self, cov: np.ndarray, sorted_idx: list[int]) -> np.ndarray:
        '''Allocation récursive par inverse-variance sur les clusters'''

    def fit(self, returns: pd.DataFrame) -> pd.Series:
        '''Pipeline complet: corr → distance → linkage → quasi-diag → bisection
        Retourne pd.Series avec les poids par actif, sommant à 1.0
        Applique min_weight et max_weight en post-processing'''
"

HRP vs autres méthodes sur notre univers (backtest 2010-2025)

Le combo Kelly + HRP domine sur le Calmar ratio (rendement/risque), exactement ce qu'on veut pour notre objectif 100K → 1M avec max DD 25%.

Risk Budgeting — Chaque stratégie a son budget de risque

Le risk budgeting ajoute une couche au-dessus de HRP : au lieu d'allouer du capital, on alloue du risque. Chaque stratégie reçoit un budget de risque proportionnel à son Sharpe ratio historique et à la confiance qu'on lui accorde.

Le framework de confiance — 4 dimensions

Allocation pratique pour nos N stratégies

claude -p "Implémente un RiskBudgetAllocator dans portfolio/risk_budget.py :

class RiskBudgetAllocator:
    '''Alloue les budgets de risque aux stratégies actives.

    Workflow:
    1. Pour chaque stratégie, calculer le score de confiance composite
    2. Calculer le budget de risque: RB_i = Sharpe_i * confidence_i / sum
    3. Convertir en poids cible via: w_i = RB_i / vol_i (poids inverse-vol)
    4. Normaliser: sum(w) = 1 - cash_buffer (5%)
    5. Appliquer les contraintes hard (max 25% par stratégie)

    Inputs: dict of strategy_name -> StrategyMetrics(sharpe, vol, n_trades,
            sharpe_oos, months_live, has_thesis)
    Output: dict of strategy_name -> target_weight
    '''

    def rebalance(self, metrics: dict, regime: str,
                  current_weights: dict) -> dict:
        '''Calcule les nouveaux poids avec turnover penalty.
        Si le changement de poids < 2%, ne pas rebalancer (hysteresis).
        En Risk-Off: réduire le budget global de 30%, augmenter cash.
        '''
"

Exemple concret — Nos 8 stratégies en production

Notez comment en Risk-Off, les stratégies mean-reversion et dual momentum augmentent leur poids (elles performent en marché baissier), tandis que le momentum cross-section est réduit. Le cash buffer passe de 5% à potentiellement 35%.

Système de contraintes multi-niveaux

Les contraintes sont les règles non négociables du portefeuille. Elles protègent contre les scénarios extrêmes que l'optimiseur ne peut pas modéliser. Notre système opère sur 4 niveaux hiérarchiques :

Niveau 1 — Contraintes par position

Niveau 2 — Contraintes par région

Niveau 3 — Contraintes par secteur

Niveau 4 — Contraintes de portefeuille

Implémentation du Constraint Engine

claude -p "Implémente un ConstraintEngine dans portfolio/constraints.py :

class PortfolioConstraints:
    '''Contraintes hard sur 4 niveaux hiérarchiques.

    Méthode enforce():
    1. Calculer les poids bruts (output de HRP + Kelly)
    2. Pour chaque niveau (position → région → secteur → portefeuille):
       a. Vérifier si une contrainte est violée
       b. Si oui, redistribuer l'excès proportionnellement aux autres
       c. Logger chaque ajustement (pour audit)
    3. Vérifier les contraintes de portefeuille (beta, DD, turnover)
    4. Si drawdown > -15%: mode DEFENSIVE (halve exposure)
    5. Si drawdown > -25%: mode EMERGENCY (all cash, Discord alert)

    La redistribution est itérative (max 10 passes) pour gérer les
    cascades (ex: réduire tech→ redistribuer→ dépasser healthcare→ ...)

    Output: dict[str, float] poids finaux respectant TOUTES les contraintes
            + list[str] log des ajustements effectués
    '''
"

Méta-Allocateur — Orchestrer N stratégies dynamiquement

Le méta-allocateur est la couche la plus haute de l'architecture. Il combine le Kelly, le HRP, le risk budgeting et les contraintes en un seul pipeline qui décide chaque jour : combien allouer à chaque stratégie, et quand promouvoir, réduire ou désactiver une stratégie.

Architecture du pipeline quotidien

claude -p "Implémente le MetaAllocator dans portfolio/meta_allocator.py :

class MetaAllocator:
    '''Orchestrateur principal du portefeuille de stratégies.

    Pipeline quotidien (exécuté à 20h00 UTC):
    ┌─────────────────────────────────────────────────┐
    │ 1. REGIME DETECTION                              │
    │    → Identifier RiskOn/Neutral/RiskOff           │
    │    → Mettre à jour les regime_weights             │
    ├─────────────────────────────────────────────────┤
    │ 2. STRATEGY HEALTH CHECK                         │
    │    → Pour chaque stratégie active:               │
    │       - Rolling Sharpe (60d) > 0 ?               │
    │       - Max DD récent < 2× DD historique ?       │
    │       - Corrélation réalisée ≈ corrélation prévue?│
    │    → Marquer: HEALTHY / WARNING / CRITICAL       │
    ├─────────────────────────────────────────────────┤
    │ 3. KELLY SIZING                                  │
    │    → compute_kelly() pour chaque stratégie       │
    │    → Shrinkage bayésien                          │
    ├─────────────────────────────────────────────────┤
    │ 4. HRP DIVERSIFICATION                           │
    │    → Matrice de corrélation inter-stratégies     │
    │    → HRP weights                                 │
    ├─────────────────────────────────────────────────┤
    │ 5. RISK BUDGET OVERLAY                           │
    │    → Ajuster selon confiance et régime           │
    ├─────────────────────────────────────────────────┤
    │ 6. CONSTRAINT ENFORCEMENT                        │
    │    → 4 niveaux de contraintes hard               │
    │    → Circuit-breaker si DD > -25%                │
    ├─────────────────────────────────────────────────┤
    │ 7. TRADE GENERATION                              │
    │    → Delta entre poids actuels et poids cibles   │
    │    → Filtrer les deltas < 2% (hysteresis)        │
    │    → Générer les ordres d'achat/vente            │
    └─────────────────────────────────────────────────┘

    Le pipeline est IDEMPOTENT : exécuter 2× donne le même résultat.
    '''

    def daily_rebalance(self) -> list[Order]:
        regime = self.regime_detector.detect()
        health = {s: self.health_check(s) for s in self.strategies}
        active = {s for s, h in health.items() if h != 'CRITICAL'}
        kelly_weights = self.kelly.compute_portfolio_weights(active)
        hrp_weights = self.hrp.fit(self.get_strategy_returns(active))
        combined = self.risk_budget.rebalance(kelly_weights, hrp_weights, regime)
        final = self.constraints.enforce(combined, regime)
        orders = self.generate_orders(final, self.current_weights)
        return orders
"

Lifecycle d'une stratégie — De l'idée à la retraite

Règles automatiques de promotion/dégradation

claude -p "Implémente le StrategyLifecycleManager dans portfolio/lifecycle.py :

class StrategyLifecycleManager:
    '''Gère les transitions automatiques entre phases.

    Règles de PROMOTION (vérifiées chaque dimanche 18h):
    - PAPER → PILOT: tracking_error < 5% ET sharpe_paper > 0.5 ET durée >= 14j
    - PILOT → RAMP_UP: sharpe_live > 0.5 ET max_dd < 10% ET durée >= 30j
    - RAMP_UP → PRODUCTION: sharpe_live > 0.6 ET stable vs paper ET durée >= 30j
    - PAUSED → PILOT: sharpe_rolling_14d > 0.3 ET cause_pause résolue

    Règles de DÉGRADATION (vérifiées chaque jour 21h):
    - PRODUCTION → PAUSED: rolling_sharpe_60d < 0 OU max_dd_recent > 2× historique
    - RAMP_UP → PAUSED: max_dd > 12% OU sharpe < 0.2
    - PILOT → PAPER: max_dd > 15% OU sharpe < 0
    - PAUSED → RETIRED: durée_pause > 90 jours

    Règle EMERGENCY (vérifiée en continu):
    - Toute stratégie avec DD > 20% → PAUSED immédiatement + alerte Discord

    Chaque transition est loggée avec: timestamp, stratégie, from_phase,
    to_phase, raison, métriques au moment de la transition.
    '''

    def check_promotions(self) -> list[Transition]:
        ...

    def check_degradations(self) -> list[Transition]:
        ...

    def emergency_check(self) -> list[Transition]:
        ...
"

claude -p "Écris les tests unitaires pour StrategyLifecycleManager.
Scénarios à couvrir:
1. Promotion PAPER→PILOT après 14j avec bon sharpe
2. Promotion refusée si durée < 14j
3. Dégradation PRODUCTION→PAUSED si rolling_sharpe < 0
4. Emergency pause si DD > 20%
5. PAUSED→RETIRED après 90 jours
6. Double transition impossible (pas de PAPER→PRODUCTION directe)
7. Transition loggée correctement avec métriques
Utilise pytest + fixtures avec des données synthétiques."

Visualisation de l'allocation dans le temps

Le graphique ci-dessus montre l'évolution typique de l'allocation sur 12 mois. Notez comment :

• Les stratégies momentum dominent en Risk-On (janvier-février, avril-juillet)
• Les stratégies mean-reversion et dual momentum prennent le relais en Risk-Off (mars, août)
• Le cash buffer augmente significativement pendant les périodes de stress
• De nouvelles stratégies entrent progressivement (PILOT → RAMP_UP → PRODUCTION)

Prochaine étape — Exécution & Market Microstructure

Maintenant que nous savons combien allouer à chaque stratégie et chaque position, il faut résoudre le comment : comment exécuter les ordres sans impact de marché ? Comment gérer le slippage, les frais, et les horaires multi-marchés ? C'est l'objet de la Partie 5.