CitizOS · Trading · Doctrine
Doctrine versionnée · publique · datée

16 versions. Une seule question.

Comment savoir si une décision est juste · pas si elle est jolie ? Chaque version de la doctrine répond à une question précise qui s'est posée pendant la construction du système. Aucune n'est gravée dans le marbre. Chacune est versionnée pour que vous puissiez voir où la pensée a évolué, et pourquoi.

16 versions publiées Période : mai 2026 Méthode itérative

Comment lire cette doctrine

Chaque version contient trois choses :

  1. Le contexte · pourquoi cette version a été nécessaire
  2. Le principe · une phrase qui résume la conviction
  3. L'impact concret · ce que cela a changé dans le système

La doctrine n'est pas du marketing. C'est l'historique de décisions techniques avec leur justification. Si une version contredit une précédente, c'est dit. Si une version est inspirée d'un échec, c'est dit. C'est l'inverse d'un livre blanc.

Versions structurantes
V1 — V3
L'architecture side-car.
2026-05-19

Un agent de trading existait déjà · un script Python de 1 596 lignes qui scannait des paires Binance toutes les 5 minutes. Modifier ce code directement aurait été dangereux · trop de logique imbriquée, trop de risque de casser ce qui fonctionnait.

La décision · construire un système parallèle · pas un remplacement. Le Decision OS observe l'agent existant, le lit, le compare, mais ne touche jamais une ligne de son code. Mode shadow strict · aucune action prise en réel.

"On n'efface pas ce qui marche pour construire ce qu'on espère."
Impact concret
Modules isolés dans /opt/citizos/trading/ · services systemd indépendants stoppables individuellement · agent_trader.py inchangé · principe d'invariant verrouillé pour toute la suite.
V4 — V5
Mesurer avant d'activer.
2026-05-19

Un système peut sembler intelligent sans l'être réellement. Une décision peut paraître bonne sans avoir été mesurée. La V4 a posé la règle qui guide encore tous les modules suivants · tout module doit prouver sa valeur statistique en mode shadow avant activation.

Concrètement · le système compare chaque décision IA avec ce qu'aurait fait l'agent classique, calcule le P&L hypothétique sur les heures suivantes, et stocke ces comparaisons en base. Aucune affirmation sans donnée.

"Plus de trades ≠ plus de profit."
Impact concret
Module shadow_comparator + shadow_pnl_analyzer · 6 630 comparaisons accumulées · 265 P&L calculés · première preuve mesurée que l'IA refuse 90,6 % de trades perdants.
V6 — V7
Robustesse avant vitesse.
2026-05-19

Tentation universelle dans tout projet quant · activer dès qu'on a quelques bons résultats. C'est le piège qui détruit la plupart des stratégies. La V6 a durci les critères · pas d'activation avant 30 jours minimum de données live, sur au moins 3 régimes marché différents.

Pourquoi ? Parce qu'un edge qui fonctionne dans un seul contexte n'est pas un edge · c'est de la chance interprétée. La robustesse multi-régimes est ce qui sépare un système durable d'un système éphémère.

"Lent à valider · durable."
Impact concret
Mode shadow verrouillé pour 30-60 jours minimum · 9 conditions marché évaluées en continu · veto automatique sur régimes destructeurs · pas de précipitation possible.
V8 — V9
L'humain dans la boucle.
2026-05-19

Un système qui se reconfigure tout seul est un système qui dérive. C'est la leçon classique des systèmes auto-adaptatifs · ils finissent par optimiser pour le bruit plutôt que pour le signal. La V8 introduit l'anti sur-filtrage · ne pas refuser tellement de trades que la fréquence devient nulle.

La V9 ajoute le principe complémentaire · le système peut recommander des changements (activer, désactiver, ajuster), mais c'est toujours un humain qui décide. Pas de boucle d'auto-modification automatique tant que les données live ne sont pas largement validées.

"Le système propose. L'humain dispose."
Impact concret
Module module_evaluator · scoring automatique 0-100 par module · recommandations stockées en DB avec human_validation = pending · aucun changement appliqué sans validation manuelle.
V10 — V11
Comparaison contre baselines.
2026-05-19

Comment savoir si on bat le marché ? Pas en se comparant à soi-même. La V11 introduit le critère le plus dur · tout module doit surperformer au moins une baseline simple sur 30 jours. Pas une, mais cinq baselines de référence ·

  • Buy & Hold BTC · stratégie passive de référence
  • DCA (Dollar Cost Averaging) BTC · achat régulier sans timing
  • Momentum basique · suit la tendance avec MA50
  • RSI baseline · BUY si RSI < 30, SELL si > 70
  • Random baseline · trades aléatoires pour mesurer le bruit
"Si on ne bat pas le hasard, ce n'est pas un edge."
Impact concret
Premier benchmark sur 14 heures de données · résultat brut publié sur le dashboard · TOS sous-performe Buy & Hold dans cette première fenêtre · acté publiquement comme phase shadow.
Le pivot
V12
Savoir quand ne pas trader.
2026-05-19

C'est la version qui change tout. Après des semaines d'observations, une conclusion s'impose · le système ne crée pas de valeur en multipliant les trades. Il crée de la valeur en refusant les mauvais trades.

Les chiffres sont sans ambiguïté · sur les 265 trades évalués, l'agent classique aurait perdu en moyenne -9,17 % par trade. Le filtre IA a refusé 90,6 % d'entre eux. L'edge n'est pas dans la sélection des bons trades · il est dans l'évitement systémique des mauvais.

"L'edge moderne n'est plus dans le signal. Il est dans le filtrage."

Cette V12 réoriente toute la stratégie produit · CitizOS Trading ne sera jamais un service de signaux. C'est une infrastructure de filtrage décisionnel. Une différence philosophique majeure.

Impact concret
Hiérarchie de décision verrouillée · Macro → Entropy → Régime → Risk → Setup → Decision. À chaque étage, la possibilité de refuser est primordiale.
V13 — V14
Séparation moteur / produit.
2026-05-19

Deux activités très différentes ne doivent pas se contaminer · construire un système de décision scientifique (le moteur TOS) et construire une marque commerciale (CitizOS Trading). La pression du produit peut pousser à activer le moteur trop tôt. L'attente du moteur peut bloquer le produit.

La V13 a posé une frontière nette · le moteur reste en phase shadow tant que les benchmarks ne le justifient pas. Le produit avance en parallèle · branding, doctrine publique, dashboard d'observation, formation. Les deux tracks ne se contaminent jamais.

La V14 a verrouillé quatre décisions structurantes · domaine citizos.trading · Pro 49 €/mois · Observer gratuit avec email · premier launch via la formation (pour décorréler les revenus initiaux des performances live).

"On ne lance pas un produit sur les performances qu'on n'a pas encore."
Impact concret
Cash-flow initial décorrélé du moteur · crédibilité construite via la pédagogie · pas de pression "à prouver" qui pousserait à des décisions techniques pressées.
V15 — V16
Profondeur éditoriale.
2026-05-19

Deux pièges identifiés dans la phase de communication · répéter en boucle le mantra "savoir quand ne pas trader" sans le démontrer, et ressembler à un faux hedge fund marketing noir/or sans profondeur réelle. La V15 a verrouillé le format des emails · 1 insight + 1 exemple concret + impact émotionnel · pas de pavé.

La V16 va plus loin · le ton luxe quant ne tient que si la profondeur intellectuelle suit. Chaque cas réel doit être documenté. Chaque décision doit être expliquée. Chaque module doit avoir sa page pédagogique. C'est l'inverse du marketing creux.

"L'esthétique ne vaut que si elle est habitée par la rigueur."
Impact concret
Pages /doctrine + /about + /benchmarks construites avec contenu réel · snapshots journaliers publics · documentation des 16 modules en cours · stratégie contenu organique avant toute acquisition payante.
Ce qui ne change pas

Les invariants

Certaines règles ne sont jamais remises en question dans les versions successives ·

  1. Aucune position prise en réel pendant la phase shadow · vérifiable en code
  2. Pas de promesse de rendement · jamais · dans aucune communication
  3. Tout module testé contre baseline · sinon supprimé
  4. Pas d'auto-reconfiguration · validation humaine obligatoire
  5. Backup avant toute modification · py_compile vérifié avant restart
  6. Doctrine versionnée publiquement · même quand elle dit "j'avais tort"

La prochaine version sera la V17. Elle existera parce qu'on aura observé quelque chose qu'on ne savait pas avant.