J'ai essayé de faire attraper à un LLM ses propres erreurs fiscales. Il ne peut pas, et c'est devenu tout le business.

L'affirmation était grammaticalement parfaite. C'était ça le problème.

Je me souviens encore de la première position qui m'a fait m'arrêter et poser mon café. Une IA avait rédigé une phrase sur la nouvelle déduction d'intérêts de prêt automobile OBBBA, et elle disait : « la nouvelle déduction d'intérêts de prêt automobile OBBBA est une déduction above-the-line qui réduit l'AGI du client. » La phrase était nette. Elle était assurée. Elle était formatée comme toutes les positions défendables que je n'avais jamais lues. Et elle était fausse exactement de la façon qui coûte à une vraie personne de l'argent réel.

La déduction d'intérêts sur prêt de véhicule de tourisme qualifié (QPVLI) est une déduction below-the-line au sens de §63(b)(7). Elle ne réduit pas le revenu brut ajusté. La placer above the line n'est pas une faute d'orthographe que l'on rattrape en relisant. Elle déplace discrètement l'AGI, et l'AGI est le chiffre sur lequel repose la moitié de la déclaration. Ce qui m'a surpris, ce n'était pas qu'un modèle se trompe légèrement sur une disposition. C'était à quel point bonne la mauvaise réponse avait l'air.

Une citation hallucinée est facile à attraper. Une mauvaise classification assurée, rédigée dans un anglais fiscal parfait, c'est celle qui se retrouve déposée.

C'est à ce moment-là que le vrai problème est devenu clair pour moi. L'industrie a passé trois ans à automatiser la rédaction du travail fiscal, et elle a vraiment bien fait. Thomson Reuters prépare automatiquement les 1040. CCH Axcess rédige des analyses consultatives dans des milliers de cabinets. Blue J répond aux questions de recherche en langage clair. La préparation est en train d'être résolue. Mais l'étape après la préparation, celle où quelqu'un doit décider si la position est réellement défendable au regard de la loi, a été confiée au même modèle probabiliste qui l'avait rédigée. Et en vertu de l'IRC §6662, la pénalité de 20 % liée à l'exactitude tombe sur l'humain qui a signé la déclaration, pas sur l'algorithme qui l'a écrite.

J'ai passé une semaine à essayer de faire en sorte que le modèle note ses propres devoirs.

Mon premier réflexe était l'évidence, et je veux être honnête : je l'ai poursuivi plus longtemps que je n'aurais dû. Si le modèle peut rédiger la position, un prompt suffisamment bon devrait pouvoir la faire vérifier. Alors j'ai essayé. Je lui ai donné la disposition. Je lui ai donné la règle QPVLI énoncée clairement. Je lui ai demandé d'auditer sa propre sortie et de signaler tout ce qui mettait une déduction sur la mauvaise ligne.

Il en a attrapé certaines. Il en a manqué d'autres. Et les ratés étaient du genre qui fait peur, parce que lorsqu'il se trompait sur l'audit, il se trompait avec la même aisance assurée qu'à la rédaction. L'auto-contrôle traversait les mêmes poids qui avaient produit l'erreur au départ. Demander à un modèle de se surveiller lui-même, c'est demander à la chose qui a fait l'erreur d'être aussi celle qui la remarque, en utilisant le raisonnement identique qui l'a produite.

Je me souviens d'expliquer cela à un collègue et de m'entendre le dire à voix haute : « on ne peut pas faire confiance à un LLM pour surveiller un LLM. » Cette phrase, c'est le moment où le design a basculé pour moi. J'avais essayé de rendre le modèle plus exact. La vraie réponse était d'arrêter complètement de faire confiance au modèle comme juge.

On ne rend pas un système probabiliste déterministe en lui demandant poliment. On sort le verdict hors de lui.

La distinction que j'ai mis trop longtemps à intégrer, c'est que rédaction et vérification ne sont pas la même tâche rendue plus facile ou plus dure. Ce sont des problèmes différents. La rédaction récompense la fluidité, la couverture et la plausibilité, exactement ce pour quoi un modèle de langage est conçu. La vérification récompense d'avoir raison de façon prouvable sur une règle précise, et de pouvoir montrer son travail à un contrôleur qui n'était pas dans la pièce. Ce sont des tempéraments opposés. J'ai arrêté d'essayer de faire faire les deux à un seul système.

Que signifie réellement « l'agent conseille, le code décide » ?

Je veux être précis sur l'architecture à laquelle je suis arrivé, parce que la formule peut sonner comme du marketing jusqu'à ce que l'on voie où la ligne est tirée. Dans StatuteGuard, la démo que j'ai construite, le modèle de langage n'a exactement qu'un seul travail : il lit le langage fiscal en langage naturel, souvent brouillon, et propose une revendication structurée et typée. C'est la seule étape neuronale. Il est réellement bon à cela, et lorsqu'il n'est pas sûr, il s'abstient et la position remonte à un humain au lieu de recevoir un verdict deviné.

Tout ce qui suit est du code. Le verdict est décidé par un moteur de politique déterministe, du vrai OPA/Rego avec un jumeau pur Python identique, qui exécute des règles que j'ai rédigées contre le droit primaire. Extraction neuronale, vérification symbolique. Le modèle conseille. Le code décide. Et la différence n'est pas académique, parce que le code ne se laisse pas dissuader de sa réponse par un paragraphe bien écrit.

La partie à laquelle je ne m'attendais pas à tenir autant qu'aujourd'hui, c'est la lisibilité. Les politiques ne sont pas une boîte noire que je vous demande de croire. Ce sont des tables de décision et du source Rego que vous pouvez ouvrir et confronter vous-même à la disposition.

Cette capture d'écran, c'est toute la thèse en un seul panneau. Un Head of Tax devrait pouvoir s'asseoir avec son partenaire conformité, ouvrir la règle, et la confirmer contre §30D avant de faire confiance à un seul verdict. Quand la logique est un paragraphe de raisonnement de modèle, vous ne pouvez pas. Quand c'est une règle que vous pouvez lire, vous le pouvez.

Alors que se passe-t-il quand le code dit non ?

La première fois que j'ai fait passer cette position prêt automobile OBBBA par la porte finie, j'ai réellement souri. Le modèle avait rédigé la revendication « above-the-line, réduit l'AGI » exactement comme avant. Mais cette fois le moteur déterministe a regardé la revendication extraite, l'a appariée à la règle §63(b)(7) encodée, et a renvoyé un verdict dur : BLOCK. Ne pas déposer.

Ce que je trouve convaincant dans cette vue, et ce que j'espère qu'un lecteur fiscal trouvera convaincant, c'est la cascade. Le moteur ne se contente pas de dire « mauvaise ligne ». Il vous montre les cinq endroits en aval qu'une fausse réduction d'AGI corromprait : le revenu brut ajusté lui-même, l'impôt sur le revenu d'État couplé à l'AGI, la surprime Medicare IRMAA, le plancher de déduction des frais médicaux à 7,5 %, et le remboursement des prêts étudiants fondé sur le revenu. Une déduction mal classée n'est pas une seule erreur. C'est un petit rayon de souffle, et le panneau rend ce rayon visible.

Puis il anime la raison, qui est la pièce à laquelle je suis le plus attaché. Il parcourt la chaîne de citations à travers le graphe de renvois croisés de l'IRC, nœud par nœud, pour que le « non » ne soit jamais une simple assertion nue.

Voici le détail auquel je reviens sans cesse, parce que c'est celui qui prouve que ce n'est pas un problème jouet. Selon le README de la démo elle-même, l'étiquette erronée « above the line » n'est pas quelque chose que j'ai inventé pour avoir un méchant. C'est une erreur de consensus documentée que des guides grand public de préparation fiscale, y compris le site de H&R Block, ont publiée. Une mauvaise réponse plausible, bien écrite et largement répétée, c'est exactement le mode de défaillance pour lequel une porte déterministe existe. Que la foule soit assurée ne fait pas basculer la déduction vers l'AGI. C'est la disposition qui décide, et maintenant le code aussi.

L'erreur fiscale la plus dangereuse n'est pas celle qui a l'air fausse. C'est celle qui a l'air juste, sonne juste, et apparaît dans les guides de trois éditeurs.

Si vous voulez vous asseoir avec tout cela, la démo en cours est sur veriprajna.com/fr/demos/statuteguard-verifier-les-positions-fiscales-redigees-par-l-ia. Vous pouvez coller votre propre position et regarder la porte décider.

La fonctionnalité que j'ai failli rater : savoir quand dire « je ne sais pas »

Je dois admettre l'erreur que j'ai failli intégrer, parce que c'est celle que tout ingénieur construisant un outil de vérification a envie de faire. Mon premier réflexe était de faire répondre la machine à tout. La couverture semblait être l'objectif. Un outil qui renvoie un verdict sur chaque position a l'air plus abouti qu'un outil qui hausse parfois les épaules.

Ce réflexe est faux, et une position précise m'a appris pourquoi. Prenons la déduction bureau à domicile §280A. Savoir si une chambre d'amis est utilisée « régulièrement et exclusivement » comme principal lieu d'activité est un test fondé sur les faits et circonstances. Il n'y a pas de règle nette à encoder, parce que la réponse dépend de la façon dont une vraie personne utilise réellement une vraie pièce. Si je forçais le moteur déterministe à trancher, je ferais exactement ce que j'ai construit pour empêcher : fabriquer un verdict assuré là où la réponse honnête est « un humain doit regarder ça. »

La porte a donc quatre verdicts, pas deux. PASS lorsque la position est défendable. BLOCK lorsqu'elle contredit la disposition encodée. NEEDS-REVIEW lorsqu'il s'agit d'une vraie zone grise. OUT-OF-COVERAGE lorsque la disposition n'est tout simplement pas encodée dans cette version. Les deux derniers signifient la même chose honnête : une personne décide celle-ci, pas la machine. Construire le chemin d'escalade a ressemblé à admettre une limite. C'est en réalité la fonctionnalité la plus importante du produit, parce qu'une couche de vérification qui ne dit jamais « je ne sais pas » n'est qu'un second modèle qui bluffe avec des étapes supplémentaires.

Les chiffres, et exactement ce qu'ils ne prétendent pas

Je suis prudent avec le benchmark, plus prudent qu'un marketeur ne voudrait que je le sois, parce que la façon dont ces chiffres sont habituellement énoncés est un mensonge. J'ai fait tourner le moteur déterministe contre un jeu doré étiqueté de 42 positions préclassées (14 propres, 16 en erreur, 12 à escalader) et j'ai mesuré ce que la couche fait.

Sur ce jeu doré de 42 cas : 71,4 % de couverture déterministe, ce qui signifie que le moteur a résolu cette part en PASS ou BLOCK tout seul et a correctement escaladé le reste. 100 % de précision de porte, ce qui signifie qu'aucune position correcte n'a été bloquée à tort. 100 % de complétude de détection d'erreurs sur les dispositions encodées. 100 % des zones grises correctement escaladées. Le débit tournait dans les dizaines de milliers de positions par seconde (environ 58 000 dans la course dont j'ai capturé l'écran, bien que cela dépende de la machine), parce que la vérification est de l'infrastructure, pas un appel de modèle.

Maintenant la partie sur laquelle j'insiste. Ces chiffres sont vrais sur ce jeu doré, pas comme une garantie en monde ouvert. Je ne vous dirai pas que StatuteGuard est « exact à 100 % », parce que cette phrase est malhonnête dès que l'on quitte le jeu étiqueté. Ce que je vous dirai est plus subtil et, je pense, plus durable : parce que le verdict est du code déterministe, son comportement sur les dispositions encodées est reproductible et prouvable, pas une probabilité qui dérive. J'ai même recroisé chacun des 42 verdicts contre OPA 1.17.1 et le jumeau pur Python, et ils ont correspondu exactement. C'est l'affirmation derrière laquelle je peux me tenir. Elle décrit la couche, pas le modèle.

« Exactitude à 100 % » est un chiffre marketing. « Reproductible sur les dispositions encodées, avec une escalade honnête partout ailleurs » est un chiffre d'ingénierie. Je préfère livrer le second.

Et c'est pourquoi cela ne devient pas obsolète. Un meilleur modèle de base l'année prochaine ne peut toujours pas prouver à un contrôleur quelle disposition statutaire étayait quelle position. La couverture, la précision de porte et une piste d'audit déposable sont des propriétés de la couche de vérification. Ce n'est pas un taux d'erreur de modèle qui se réduit à mesure que les modèles s'améliorent.

L'artefact dont je ne savais pas que je le construisais jusqu'à ce qu'un contrôleur le demande

Je n'avais pas pour but de construire un document de conformité, mais plus j'ai parlé à des gens du fiscal, plus la conversation finissait au même endroit : « très bien, ça a attrapé l'erreur, mais qu'est-ce que je remets à l'IRS ? » Alors chaque verdict écrit désormais un dossier de diligence raisonnable §6662 déposable, une feuille de travail imprimable qui documente que la position a été vérifiée contre la disposition avant le dépôt. Feuille source, disposition, source primaire, la revendication extraite, le récit de détermination, la chaîne complète de citations. C'est la preuve qu'une position de cause raisonnable et de diligence due a effectivement été prise, ce qui compte directement au regard des révisions AICPA SSTS en vigueur en janvier 2024.

Il y a une raison de plus pour laquelle j'accorde de l'importance à l'endroit où cela tourne, et elle est devenue concrète après l'arrêt Heppner (SDNY, février 2026), qui a soulevé une question de renonciation au secret professionnel sur le fait d'alimenter un outil d'IA public avec de la recherche client. StatuteGuard tourne entièrement en local sans clé API par défaut. Aucune position et aucune donnée client ne quitte le périmètre. Après Heppner, une architecture fermée, locale et auditable n'est plus seulement un plus agréable lors d'une revue de sécurité. Elle est juridiquement significative. Je n'ai pas conçu la posture local-first pour cet arrêt. Mais l'arrêt est la raison pour laquelle je mène désormais avec elle.

Pour le contexte des enjeux, les coûts de conformité fiscale des entreprises aux États-Unis dépassent 126 milliards de dollars par an (recherche solution WP1, 2026), et la pénalité IRC §6662 est de 20 % du sous-paiement, avec une exposition pour fraude §6663 atteignant 75 %. Quand la rédaction est automatisée et que la pénalité est personnelle, l'étape de vérification est celle qui devrait empêcher un Head of Tax de dormir.

Ce en quoi je crois réellement maintenant

Au départ, je pensais construire une meilleure IA fiscale, et je veux finir en disant clairement que je me trompais sur ce qu'était le problème. Votre IA fiscale n'a pas un problème d'exactitude. Elle a un problème de vérification, et un meilleur modèle ne le corrigera pas, parce que la pénalité de 20 % tombe sur votre signature, pas sur ses poids. Personnaliser et automatiser la rédaction du travail fiscal est un vrai progrès. Ce n'est pas non plus la même chose que de prouver qu'une position est défendable, et l'industrie les a discrètement traités comme s'il s'agissait de la même chose.

La démo vit sur veriprajna.com/fr/demos/statuteguard-verifier-les-positions-fiscales-redigees-par-l-ia si vous voulez essayer de casser la porte. J'aimerais vraiment que vous le fassiez.

Et si vous préférez regarder la porte décider plutôt que de me lire la décrire, voici le tout qui tourne de bout en bout.

Voici donc la question que je n'arrête pas de poser aux dirigeants fiscaux, et je n'ai pas encore de réponse confortable. Quand une IA rédige une position et que vous signez la déclaration, quel est l'artefact qui prouve que vous l'avez vérifiée, plutôt que de lui avoir fait confiance ? Si la réponse honnête est « rien, j'ai fait confiance au modèle », alors le modèle n'est pas votre assistant. C'est votre cosignataire, et on ne peut pas le convoquer à l'audit.