Faire auditer son code par une autre IA : 25 défauts confirmés sur 27

Un juge de stratégies de trading doit pouvoir être pris en défaut. Le moyen le plus rapide d'y arriver, c'est de le confier à quelqu'un qui n'a aucune raison de le ménager. En octobre 2026, nous avons confié la Lab, notre backtester et juge local, à une autre IA : Codex. Deux audits : l'un en utilisant la Lab par MCP, comme le ferait n'importe quelle IA cliente, l'autre en lisant le code source.

Voici la méthode, les constats et ce qui a été corrigé. C'est aussi un retour d'expérience pour quiconque fait écrire du code par une IA : un deuxième modèle, avec une consigne précise, trouve des choses que le premier ne voit pas.

La consigne

Codex devait chercher tout ce qui permettrait d'obtenir un verdict « résiste » sans le mériter, et tout ce qui rend un reçu ou un chiffre publié faux. Chaque constat devait venir avec un fichier, une ligne et un scénario chiffré. Pas d'impression générale : un défaut qu'on peut rejouer.

La vérification : rien n'est cru sur parole

Les constats de Codex ont été traités comme des données d'entrée, pas comme des conclusions :

• chacun a été vérifié contre une copie gelée du code (version 245), jamais modifiée ;
• quand c'était possible, il a été reproduit : appels MCP réels à la Lab installée, ou tests Rust écrits pour réussir tant que le défaut est présent (4 sur 4) ;
• les constats statistiques ont été recalculés indépendamment ;
• aucune preuve n'a été lancée pendant la vérification, pour ne consommer aucune période de test scellée.

Le bilan

25 constats confirmés sur 27. La gravité retenue diffère parfois de celle proposée par Codex : plusieurs constats notés « majeurs » se sont révélés mineurs une fois mesurés (un chiffre descriptif décalé, un cas limite borné), et les deux constats réfutés étaient des refus intentionnels, ce que Codex signalait lui-même. Le tri entre « défaut » et « limite assumée » reste le travail de celui qui vérifie.

Les cinq plus graves

1. Le Sharpe déflaté se changeait en prime. Le Sharpe déflaté pénalise un résultat selon le nombre d'essais. Avec un nombre effectif d'essais à peine supérieur à 1 (deux variantes presque identiques), l'approximation de la référence devenait négative : la pénalité devenait un bonus. Reproduit : 99,9999991 % au lieu de 53,98 %, sur l'une des portes du verdict « résiste ». La référence était négative pour tout N compris entre 1 et 1,28.

2. L'export Pine d'une preuve changeait de période. Une stratégie jugée sur 2 000 bougies s'exportait vers TradingView sur 17 971, sans ses frais ni sa politique d'exécution, tout en déclarant « même stratégie ». Bloquant pour quiconque veut reproduire un verdict.

3. Un stop ATR pouvait ne jamais exister. Dans le moteur à lots, un lot acheté avant que l'ATR soit calculable n'avait pas de stop. Reproduit : trois lots tenus jusqu'à −35,6 % malgré stop_loss: 2 * ATR(14).

4. « Stop d'abord » était affiché, pas appliqué. Quand une bougie touche à la fois le stop et l'objectif, l'option prudente figurait dans le reçu, mais 262 lots sortaient quand même en objectif. L'utilisateur qui choisissait la prudence obtenait des chiffres plus optimistes qu'il ne le croyait.

5. Le Monte Carlo oubliait les positions ouvertes. Les épisodes perdaient le rendement des lots encore ouverts (produit de 1,4545 au lieu de 1,6). La probabilité de perte publiée dans les rapports était fausse, sans effet sur le verdict.

D'autres constats touchaient la façon dont une IA utilise la Lab : le parcours d'accueil start_here menait à un export Pine sans passer par le juge, avec des réglages écrits en dur ; trois arguments recommandés par la documentation étaient refusés par le schéma publié ; un backtest en profil complet renvoyait 189 179 octets, de quoi remplir le contexte d'un modèle.

Ce qui a été corrigé

La version 246 apporte 21 corrections issues de ces audits :

• Sharpe déflaté : la référence ne descend jamais sous zéro et croît avec le nombre d'essais. Le même cas donne 53,22 %.
• Export Pine : l'export garde la fenêtre, les frais, la politique d'exécution et les empreintes du script et des données. Il ne trade qu'à partir du début de la période de test. Contrôle : 2 000 bougies exportées, et le Pine rejoue les mêmes trades que la preuve (10 sur 10 et 95 sur 95 selon le moteur).
• Stop ATR : plus aucun achat tant que son stop n'est pas calculable ; premier achat à l'indice 13 dans le cas reproduit, chaque lot porte son stop.
• Stop d'abord : appliqué sur CPU et sur GPU, avec des résultats identiques au bit.
• Monte Carlo : épisodes construits depuis l'exposition réelle ; le produit retombe à 1,6 à 10⁻⁹ près. Si la conservation échoue, pas de bootstrap : un statut d'erreur.
• Seuil du test SPA : devenu un budget partagé entre toutes les règles jugées, dont la somme reste sous 10 % ; quand le bootstrap est trop grossier pour trancher, la Lab répond « résolution insuffisante » au lieu de décider.
• Accueil MCP : start_here passe maintenant par la preuve avant l'export, sans réglage en dur ; 82 exemples d'appel validés contre le schéma de chaque profil, 0 échec ; un backtest par défaut pèse environ 9 600 octets.

Chaque correction a été suivie d'une non-régression : plus de 1 000 tests de l'application et plus de 1 200 tests du moteur, sans échec.

Le coût de la rigueur, mesuré

Des portes plus strictes laissent passer moins de faux positifs, et aussi moins de vrais signaux. Les deux côtés ont été mesurés sur la version corrigée, avec un protocole préenregistré :

• 0 faux « résiste » sur 872 preuves de bruit pur ;
• sur un scénario à signal planté, la Lab confirme le signal 2 fois sur 100, contre 11 avant la correction du seuil.

Ce coût est publié avec le reste. Nous préférons un juge qui laisse passer moins de vraies stratégies à un juge qui en invente.

Ce que ça apprend sur le code écrit avec des IA

1. Un deuxième modèle trouve ce que le premier ne voit pas. Les défauts les plus graves n'étaient pas des plantages : le code tournait, les tests passaient, les chiffres avaient l'air plausibles.
2. Exigez des constats rejouables. Fichier, ligne, scénario chiffré. Un constat qu'on ne peut pas reproduire ne se corrige pas, il se discute.
3. Vérifiez chaque constat. Ici, 25 sur 27 tenaient. Les 2 autres étaient des limites volontaires. Sans vérification, on corrige aussi ce qui n'était pas cassé.
4. Un reçu doit dire ce que le moteur fait. Trois des cinq défauts graves étaient des écarts entre ce qui était affiché et ce qui était calculé.

Les limites de cet audit : le noyau GPU du moteur à lots n'a pas été exécuté pendant la vérification (il l'a été pour les corrections), et une preuve complète montrant le défaut Monte Carlo de bout en bout n'a pas été lancée, pour ne pas consommer de période scellée. La version 246 est construite et en cours de vérification ; la page de téléchargement sert encore la 243.

Le premier défaut, trouvé par nous-mêmes, est raconté ici : comment notre juge de backtest s'est pris en défaut. La boucle de recherche automatique, mesurée sur du bruit : une IA peut-elle trouver une stratégie de trading ?. Et pour comparer les IA entre elles : Claude, ChatGPT ou Grok pour trader.

Vous voulez faire auditer la Lab par votre propre IA, ou lui faire juger vos stratégies ? Le guide MCP explique comment brancher Claude Code, Codex, opencode avec DeepSeek ou un modèle local. La Lab est gratuite.

À retenir

• 27 constats distincts de Codex, 25 confirmés (20 reproduits, 5 par lecture), 2 réfutés comme limites volontaires.
• Le plus grave : un Sharpe déflaté à 99,99 % au lieu de 54 % avec très peu d'essais ; corrigé, 53,2 %.
• 21 corrections dans la 246, dont l'export Pine qui garde sa période et ses frais.
• Remesuré : 0 faux « résiste » sur 872 preuves de bruit ; coût publié, 2 sur 100 au lieu de 11 sur un signal planté.
• Un juge incorruptible n'est pas un juge sans erreur : c'est un juge qui se fait auditer et corrige en public.

Recherche sur données passées, pas un conseil d'investissement. Les chiffres ci-dessus mesurent le comportement d'un logiciel sur données passées et simulées.