LedgerPilot : même Qwen, même ledger, garde-fou désactivé poste 5 mauvaises écritures, activé en poste 0

La clôture mensuelle est l'un des flux de travail les plus sujets aux erreurs en finance, et c'est aussi le pire endroit pour donner un clavier à un LLM qui hallucine. Une seule mauvaise écriture postée dans un système de référence est un ajustement d'audit, pas une commodité. Pourtant le motif commercialisé pour un agent comptable est justement de lui donner l'accès en écriture au ledger et d'espérer que les prompts tiennent. LedgerPilot est la version où le modèle a le droit de raisonner et de proposer, et jamais celui d'écrire. Chaque écriture passe d'abord par un garde-fou déterministe, et le but du projet n'est pas que l'agent poste dans un vrai ERP (beaucoup le font). C'est que le côté écriture soit mesuré.

Le contrefactuel (toute la revendication en un tableau)

Même planificateur qwen-flash, mêmes 39 tâches de clôture, même ledger Odoo en direct. Chaque proposition est postée deux fois, une avec le garde-fou désactivé, une avec activé. La seule variable, c'est le garde-fou.

• Garde-fou DÉSACTIVÉ : 39 écritures postées. 5 mauvaises écritures réellement présentes dans le ledger. Exemples de runs commités : salaires payés depuis Comptes clients (Dr 6000 / Cr 1100) au lieu de Caisse ; écriture de coût des ventes imputée à Créances et Revenus (Dr 1100 / Cr 4000) au lieu de COGS et Fournisseurs. Chacune s'équilibre, utilise de vrais comptes postables, et passe un bilan de vérification.
• Garde-fou ACTIVÉ : 34 écritures postées. 0 mauvaise écriture dans le ledger. Le compte garde-fou-désactivé bouge avec l'échantillonnage du modèle (5 à 7 selon les runs) ; le compte garde-fou-activé a été 0 à chaque run. Cette asymétrie, c'est toute la revendication, et c'est la partie qui ne dérive pas.

Le taux de mauvaises écritures, mesuré

Deux chiffres appuient le contrefactuel : la logique de décision du garde-fou est solide, et elle tient sur la vraie sortie du modèle. Sur un corpus synthétique de 204 cas (12 scénarios × 14 classes d'erreurs + contrôles propres) le garde-fou attrape 100 % des erreurs (156 bloquées + 12 escaladées) avec 0 % de faux rejets sur les contrôles propres. Sur la vraie sortie Qwen pour 39 tâches en langage naturel : qwen3.7-max est précis à 97,4 % et chaque erreur qu'il fait est attrapée ; qwen-flash est à 82,1 % et chaque erreur qu'il fait est attrapée. Le garde-fou a écrit 0 mauvaise écriture dans les deux cas (IC Wilson 95 % : ≤ 9,18 % pour max, ≤ 10,72 % pour flash).

Le plus intéressant : un modèle plus faible et moins cher (qwen-flash) fait 7 × plus d'erreurs que le flagship (qwen3.7-max), et le ledger reste propre. C'est tout l'argument du garde-fou : la justesse vient du garde-fou, pas du modèle qui a raison.

Qwen pilote l'écriture via MCP, et ne peut toujours rien écrire de faux

Le garde-fou est exposé comme serveur MCP tournant sur la boîte ECS, attaché à Qwen sur Model Studio comme outil MCP SSE via la Responses API. Le modèle est l'appelant de l'outil d'écriture, pas l'autorité. validate_write est en lecture seule. execute_approved_write rejoue tout le garde-fou et vérifie un jeton HMAC lié au hash du contenu de l'écriture avant de toucher Odoo. Trois cas de bout en bout : une écriture correcte reçoit un vrai account.move posté dans l'Odoo en direct ; le modèle sommé de gonfler le montant avant d'écrire voit le hash changer, le jeton ne se valide plus et le serveur refuse ; une écriture avec mauvais compte est refusée par le rapprochement. La falsification par le modèle appelant est détectable, pas seulement découragée. Mettre le garde-fou derrière l'outil, c'est ce qui permet de donner au modèle l'accès en écriture sans lui donner la capacité d'écrire quelque chose de faux.

Le backend tourne sur Alibaba Cloud ECS

L'agent est déployé sur une instance ECS d'Alibaba Cloud (i-t4n1i5p7bz4ypj122e6q, ecs.t6-c1m2.large, Ubuntu 24.04, ap-southeast-1), provisionnée de bout en bout par un script Python via les OpenAPI ECS et VPC. Tout dans ce billet (la suite de 79 tests, le stress-test hors ligne du garde-fou, la mesure live de Qwen, le contrefactuel contre le vrai Odoo, l'aller-retour MCP et l'ingestion de factures par vision) a été exécuté sur cette instance. Elle sert l'interface web du garde-fou sur le port 80 à ledgerpilot.jonathanandrei.com. Le transcript de preuve inclut les valeurs renvoyées par le service de métadonnées d'instance ECS, qui ne répond que sur une vraie instance ECS, donc le déploiement n'est pas seulement affirmé, il est falsifiable.

Limites honnêtes

• Le rapprochement est par document, pas par ligne. Chaque type de document porte une politique d'imputation : l'ensemble des comptes autorisés pour ce type de document. Le garde-fou enforce l'ensemble plus le montant. Un choix permis-mais-mauvais à l'intérieur de l'ensemble apparaîtrait comme un taux non nul. C'est pourquoi la métrique est falsifiable plutôt que nulle par construction ; dans les runs commités, chaque erreur du modèle est tombée hors de l'ensemble permis. En production, on escaladerait les choix vraiment ambigus à un humain plutôt que d'accepter n'importe quel compte permis.
• La mesure live varie de quelques points entre runs parce que l'échantillonnage n'est pas parfaitement reproductible à température 0. Les transcripts bruts pour les deux modèles sont commités pour que les chiffres soient vérifiables plutôt qu'affirmés. Ce qui n'a pas bougé entre runs est l'essentiel : le garde-fou a attrapé chaque erreur et écrit zéro mauvaise écriture.
• L'idempotence est sûre au réessai séquentiel, pas à la concurrence. Le client cherche le hash du contenu de l'écriture avant de créer le move, donc un re-run ne double-poste pas. Deux agents qui écrivent la même écriture au même instant pourraient encore se marcher dessus ; la production utiliserait une contrainte unique sur le hash dans l'ERP.
• Les chiffres de mauvaises écritures des 204 cas et des 39 tâches sont mesurés à partir de tâches en langage naturel et de documents source structurés, pas d'images scannées OCR. Le chemin vision est réel et exercé (Qwen3-VL-Plus lit une facture PNG et pilote le garde-fou), mais une revendication production mesurerait le taux à partir de documents scannés de bout en bout.
• Le rollback et un journal d'audit / file de revue persistants ne sont pas implémentés. Un move posté peut être annulé manuellement dans Odoo aujourd'hui ; les écritures rejetées sont refusées avec la vérification en échec comme raison, mais cet enregistrement n'est pas encore persisté dans une file.