Rapport-type d'audit de robustesse

Ce que vous lisez. Ces trois rapports n'ont pas été rédigés : ils sont la sortie brute du moteur VERIFICATOR, lancé sur des données publiques (FRED) que chacun peut retélécharger. Chaque audit s'exécute en moins d'une seconde.

Trois principes, inscrits dans le code et non dans un slogan. (1) Le verdict est ternaire : maîtrisé, sous-estimé, ou non concluant — ce dernier est un verdict de plein droit, rendu quand les données ne permettent pas de trancher, plutôt qu'un chiffre rassurant. (2) Chaque verdict cite sa preuve : une étude pré-enregistrée dont la prédiction chiffrée a été scellée par empreinte SHA256 avant tout calcul, résultats négatifs publiés au même rang. (3) Le rapport porte l'empreinte des données auditées : il est re-vérifiable.

Un audit qui alerterait sur tout n'aurait aucune valeur. Vous verrez ci-dessous des verdicts verts francs à côté des alertes — c'est ce qui rend les alertes crédibles.

Ce que nous ne pouvons PAS vérifier — et que nous préférons écrire. L'audit ne voit que la période qu'on lui soumet. Nous avons mesuré ce que cela coûte plutôt que de le taire (étude P243, 9 séries publiques) : en choisissant la période, 56 % des verdicts défavorables se retournent en moins de dix essais. L'exposition dépend de l'axe — le risque de queue y résiste (aucune période favorable trouvée sur 9 séries), la mémoire de la volatilité cède en 1,5 essai. Et aucune parade automatique n'existe (étude P244) : ce choix ne laisse pas de trace détectable dans les données reçues. La seule défense est donc une déclaration signée du client, exigée par le moteur avant tout calcul — pas un contrôle de notre part.

Verdict, et l'aveu qui compte. Le modèle gaussien s'est trompé d'un facteur ≈575 sur le nombre de séances au-delà de 4σ. L'audit a réduit cette erreur d'environ cent fois. Mais il sous-estimait encore la crise d'un facteur ≈5, et nous l'écrivons plutôt que de le taire : la queue mesurée sur l'historique sous-estime elle-même les crises, car une crise ne réalise pas seulement la queue passée — elle en crée une plus lourde.

Conséquence opérationnelle : dimensionner le capital sur la queue empirique vaut infiniment mieux que sur σ, mais ce n'est pas encore assez — il faut y ajouter une marge de régime. Un audit qui prétendrait avoir « vu venir 2008 » mentirait ; celui-ci dit de combien chaque modèle s'est trompé, y compris lui-même.

1. Le moteur valide un bon modèle. Sur 2005-2019 il rend un vert franc — AUC 0,94, calibration excellente, +40 % de gain sur le prophète constant. Un outil qui alerterait aussi ici n'aurait aucune valeur : c'est ce vert qui rend les alertes crédibles.

2. Le même modèle est démasqué sur l'autre régime. Son pouvoir de tri tombe au niveau du hasard et son gain de Brier devient négatif de plus de 1 200 % : le modèle est environ treize fois pire que d'annoncer simplement le taux de base. Un modèle muet aurait mieux servi.

3. Le risque de modèle dans sa forme la plus coûteuse. Un modèle authentiquement excellent devient nuisible sans qu'une ligne de son code ne change — sa validation initiale était justifiée, c'est le monde qui a changé. Aucune validation interne classique ne le voit, parce qu'elle re-mesure la performance sur la période de calibration. Il faut mesurer par régime et comparer au prophète constant : les deux gestes que ce moteur fait automatiquement.

Verdict rendu : « écart à Benford RÉEL mais expliqué par une cause STRUCTURELLE : écart stable sur les 3 périodes (coefficient de variation du MAD = 0,04), signature d'un barème permanent — pas d'une fraude. Conclure à la fraude ici serait un faux positif. »

Pourquoi c'est le raisonnement qui compte. Une fraude apparaît, s'aggrave ou cesse ; un barème, lui, produit exactement le même biais chaque année. Ces aides sont proportionnelles à des surfaces : leur distribution n'a aucune raison de suivre Benford, et n'en suit pas. Envoyer un client enquêter là-dessus lui coûterait cher pour rien.

Ce que nous ne prétendons pas. Ce détecteur est validé sur ce qu'il évite (le faux positif) et sur son domaine de validité — pas sur un cas de fraude réelle avérée. Nous ne dirons donc pas qu'il « détecte la fraude » : il écarte une famille d'anomalies et refuse d'accuser à tort.

Pourquoi ce n'est pas un détail. En testant nos propres entrées dégradées, nous avons découvert que le moteur écrivait un rapport « 3 axes · 1 alerte » lorsque le fichier de données était introuvable — un rapport d'apparence sérieuse, avec une alerte donc crédible, sur des données jamais lues. C'est précisément la faute que ce produit dénonce chez les autres outils. Elle est corrigée, et la barrière est désormais publiée ici.

Le verdict « non concluant » obéit à la même règle : quand les données ne permettent pas de trancher, l'audit le dit — et la raison est écrite dans le rapport, avec ce qu'il faudrait fournir pour lever le doute.

Un incident, conservé volontairement. À sa première exécution, le banc a donné 0 % de sensibilité au détecteur de mémoire de volatilité. Enquête faite, le coupable n'était pas le détecteur mais notre propre générateur de test, qui produisait une volatilité quasi constante (autocorrélation 0,06 — rien à détecter). Corrigé en vrai GARCH(1,1), le détecteur passe à 100 %. Nous laissons la trace : un banc d'essai sert d'abord à se méfier de soi.

Et ce banc, que vaut-il ? Un tableau de verdicts conformes ne prouve rien s'il ne sait pas repérer une panne. Nous l'avons donc mesuré par la méthode consacrée (mutation : saboter délibérément son propre code et compter les sabotages détectés) : 7 sur 9. Le banc voit qu'un instrument est cassé ; il ne voit pas un seuil qui dérive quand un autre calcul couvre le cas. Nous préférons afficher cette limite plutôt que le seul chiffre flatteur — et une suite distincte, dont chaque test a été prouvé capable d'échouer, protège les sept fautes déjà corrigées.