À qui s’adresse cette page — À quiconque gère une stratégie déjà autorisée et doit distinguer un incident technique, un problème d’exécution, une détérioration possible du modèle, un changement de régime et la variabilité normale avant de décider de la limiter ou de la suspendre.
La surveillance d’une stratégie compare en permanence le comportement observé, les hypothèses validées et les limites opérationnelles. La suspension est l’une des actions de contrôle possibles : elle empêche de prendre de nouvelles expositions ou limite certaines parties du processus pendant que le capital est protégé et que le diagnostic est mené. Elle ne constitue pas une conclusion automatique sur la valeur économique du modèle.
Une alerte indique qu’une mesure a franchi une condition prédéfinie ; à elle seule, elle n’en établit pas la cause. Un même drawdown peut provenir de la variabilité normale, de prix corrompus, d’ordres dupliqués, d’un changement du slippage ou de l’affaiblissement d’une relation prédictive. Arrêter une stratégie après un nombre fixe de pertes consécutives revient à confondre la séquence observée avec un diagnostic et peut entraîner des arrêts et redémarrages procycliques.
Taxonomie des écarts
| Classe | Signaux observables | Première question | Réponse possible |
|---|---|---|---|
| Incident de données ou incident opérationnel | Flux périmé, valeurs impossibles, processus arrêté, position non rapprochée | Le système dispose-t-il d’un état fiable ? | Bloquer, rapprocher, corriger ou effectuer un rollback |
| Dérive d’exécution | Rejets plus nombreux, fills dégradés, latence, impact ou disponibilité des titres à emprunter modifiés | La mise en œuvre s’est-elle éloignée de ses hypothèses ? | Réduire la taille, changer le routage, recalibrer la capacité |
| Détérioration du modèle | Erreurs de prévision ou payoffs durablement hors des attentes | La relation modélisée reste-t-elle compatible avec les données ? | Révision indépendante et revalidation |
| Changement de régime | Modification générale de la volatilité, de la liquidité, des corrélations ou de la structure | Le processus externe pertinent a-t-il changé ? | Limites de régime, réduction ou suspension motivée |
| Variabilité normale | Fluctuations comprises dans l’incertitude prévue | L’événement était-il plausible selon le modèle validé ? | Poursuivre sous surveillance, sans ajustement impulsif |
Ces classes peuvent coexister. Un changement de liquidité peut provoquer une dérive d’exécution et réduire le rendement net sans invalider le signal brut. Le diagnostic devrait donc décomposer les données, le signal, le portefeuille, les ordres et l’économie de l’exécution.
Des seuils motivés, pas des nombres magiques
Un seuil utile découle d’une distribution de référence, de l’importance économique et de la capacité d’intervention. Il doit préciser la métrique, la fenêtre, la fréquence, la qualité des données, la direction, le niveau de gravité et l’action. Pour un contrôle opérationnel, une tolérance presque nulle peut être appropriée — par exemple pour des ordres dupliqués ou le dépassement d’une limite absolue — tandis qu’une métrique statistique exige des intervalles et une persistance cohérents avec sa variabilité.
Le drawdown est une mesure importante du parcours, mais pas un diagnostic autonome. La séquence de pertes dépend du taux de réussite, de la dépendance, de l’asymétrie et des régimes ; il n’existe aucun nombre universel au-delà duquel une stratégie devrait être arrêtée. Même des seuils calibrés sur le même backtest peuvent être surajustés.
Une organisation à plusieurs niveaux réduit l’ambiguïté :
- avertissement, qui augmente la fréquence et la profondeur des contrôles ;
- limitation, qui réduit le risque, l’univers ou les fonctionnalités selon des règles autorisées ;
- suspension, qui empêche les nouvelles expositions tout en gérant les expositions existantes conformément à un plan ;
- kill switch, qui interrompt rapidement des fonctions définies lorsque la sécurité l’exige.
Les actions ne doivent pas dépendre uniquement du P&L. L’intégrité des données, l’état des positions, les limites de risque, les ordres anormaux et la capacité de rapprochement peuvent être prioritaires.
Protocole de surveillance et d’escalade
- Définir le périmètre validé. Version, données, marchés, taille, horaires, courtier, coûts, benchmark, dépendances et conditions d’utilisation autorisées.
- Cartographier les contrôles et leurs responsables. Attribuer à chaque métrique une source, une fréquence, un seuil, une gravité, un destinataire, une autorité d’intervention et une solution de repli.
- Séparer les indicateurs. Distinguer intégrité des données, santé opérationnelle, exécution, expositions, performance et variables de régime.
- Prédéfinir l’escalade. Établir qui peut limiter, suspendre, annuler des ordres, fermer des positions ou activer le kill switch, ainsi que la manière d’informer les fonctions concernées.
- Préserver l’état. Sauvegarder les flux, les signaux, les ordres, les fills, les positions, les logs, la configuration et les interventions avant qu’un redémarrage ou une correction n’efface des éléments probants.
- Confiner avant de diagnostiquer lorsque c’est nécessaire. L’incertitude sur la cause ne justifie pas de poursuivre si la position ou le contrôle ne sont pas fiables.
- Effectuer l’analyse des causes racines. Classer l’événement comme incident, dérive d’exécution, détérioration, changement de régime ou variabilité normale, et rechercher des causes concomitantes.
- Documenter la décision et les conditions de sortie. Le responsable, l’échéance, le risque résiduel, les communications et les preuves exigées doivent être explicites.
Kill switch, rollback et suspension
Le kill switch est un mécanisme de confinement rapide. Il peut interrompre l’envoi de nouveaux ordres, annuler les ordres ouverts ou déclencher une procédure définie pour les positions ; il n’implique pas nécessairement de tout liquider immédiatement, car une telle action pourrait augmenter le risque sur des marchés illiquides.
Le rollback rétablit une version technique antérieure et autorisée lorsque le problème est attribuable à une release ou à une configuration. Il exige que les données, l’état et les positions soient compatibles : il n’est pas toujours sûr ni possible. La suspension du modèle concerne au contraire l’utilisation de la stratégie et peut rester en vigueur après le rétablissement technique, jusqu’à la fin du diagnostic.
Réactivation, revalidation et nouvelle version
La réactivation ne devrait pas suivre la première opération favorable ni une échéance arbitraire. Après un incident purement opérationnel, la même version peut éventuellement reprendre si l’état et les contrôles ont été rapprochés et si les tests de reprise ont produit des résultats documentés. Une modification substantielle des variables, des paramètres, de l’univers, du dimensionnement, des coûts ou de la logique des ordres crée au contraire une nouvelle version.
La revalidation doit être proportionnée au changement et au préjudice potentiel : analyse de la cause, tests de régression, contrôles de robustesse, révision indépendante et nouveau forward test lorsque ces mesures sont pertinentes. La période ayant guidé la modification appartient au développement de la nouvelle version et ne demeure pas un test OOS pur.
Exemple illustratif
Exemple expressément présenté à titre illustratif — Une alerte signale des prix inchangés et une hausse du nombre d’ordres rejetés. Le contrôle suspend les nouveaux ordres, conserve les logs et les positions, puis lance le rapprochement. La cause se révèle être un flux périmé après une release : un rollback vers la version autorisée est effectué, les données et l’état sont vérifiés, et la correction est soumise à des tests de régression. L’événement n’est pas qualifié de « changement de régime » sur la seule base du P&L observé, et l’intervention n’attend pas un nombre prédéfini de pertes.
Si, au contraire, les données et les opérations sont intactes mais que les métriques s’éloignent des attentes, l’escalade peut commencer par une surveillance accrue et une réduction des limites. L’alerte reste un élément à diagnostiquer, et non la preuve immédiate que l’edge a disparu.
Limites
- Les distributions historiques peuvent sous-estimer des événements nouveaux ou des changements structurels.
- Un nombre excessif d’alertes augmente le bruit et le risque d’accoutumance ; un nombre insuffisant laisse sans contrôle des points substantiels.
- Réduire ou arrêter une stratégie peut entraîner des coûts, un impact et un risque résiduel.
- Une surveillance sophistiquée ne corrige ni un backtest contaminé ni une gouvernance dépourvue d’autorité effective.
- Les prescriptions réglementaires dépendent de la juridiction, de l’entité et de l’activité ; cette page ne détermine aucune obligation juridique individuelle.
Références
- Joseph Simonian, CFA Institute Research Foundation, Investment Model Validation: A Guide for Practitioners, 2024 — validation proactive, surveillance et fiabilité des modèles d’investissement.
- Board of Governors of the Federal Reserve System, SR 26-2: Model Risk Management, 2026 — gouvernance, validation, limites d’utilisation et surveillance ; ce texte s’applique aux organisations bancaires relevant de son champ de supervision et n’est cité ici qu’en tant que référence de gouvernance.
- Commission européenne, Règlement délégué (UE) 2017/589, RTS 6 — contrôles, tests, limites et fonctionnalités opérationnelles dans le périmètre européen du trading algorithmique auquel il s’applique.
- European Securities and Markets Authority, Supervisory Briefing on Algorithmic Trading in the EU, 2026 — gouvernance, tests, externalisation et contrôles pré-trade ; briefing de supervision non contraignant dans son propre champ d’application.
- U.S. Securities and Exchange Commission, Staff Report on Algorithmic Trading in U.S. Capital Markets, 2020 — automatisation, risques opérationnels et interaction des algorithmes avec la structure du marché américain.