Créer des agents fiscaux autoaméliorés avec Codex
Par des membres du personnel technique : Aravind Srinivasan et Samay Shamdasani (Thrive Holdings), Arthur Fernandes Araujo et John de Wasseige (OpenAI)
Comment Thrive Holdings et OpenAI ont codéveloppé Tax AI pour les comptables de Crete en fusionnant l’expertise des praticiens avec une boucle pilotée par Codex
Les systèmes du monde réel se comportent différemment en production que dans un laboratoire, et tombent en panne de façons difficiles à anticiper avant le déploiement. Les équipes découvrent souvent ces défaillances après le lancement, puis passent des semaines à inspecter les cas limites, à ajuster les invites et à traduire la rétroaction de production en améliorations durables du produit. La boucle de rétroaction est manuelle et lente, et ne s’améliore que lorsqu’un ingénieur la fait avancer. Mais aujourd’hui, avec une infrastructure d’eval bien conçue, un accès direct aux praticiens et aux environnements réels, et les capacités agentiques de pointe de Codex, vous pouvez bâtir des agents qui s’autoaméliorent.
Dans ce billet, nous expliquerons comment nous avons utilisé Codex pour bâtir ce type d’agent. Au cours des six derniers mois, des ingénieurs et chercheurs déployés sur le terrain par OpenAI, ainsi que les ingénieurs de Thrive Holdings, ont collaboré pour bâtir Tax AI aux côtés du réseau de plus de 30 cabinets comptables de Crete(s'ouvre dans une nouvelle fenêtre) et pour lui, afin d’aider à préparer des déclarations de revenus de plus en plus complexes. Au lieu de compter sur les ingénieurs pour trouver et corriger chaque défaillance, Tax AI utilise Codex pour transformer l’usage en production en signaux structurés qui alimentent une amélioration autonome.
Les praticiens de Crete préparent des dizaines de milliers de déclarations de revenus chaque saison, ce qui exige de traiter des millions de documents sous-jacents. Pour les déclarations de complexité moyenne à élevée, la seule saisie de données peut prendre huit heures par déclaration, impliquant souvent des sources de données désordonnées, des documents de l’année précédente, ainsi qu’une extraction et un calcul manuels. Ils nous ont indiqué que la préparation fiscale constituait un goulot d’étranglement important pendant la période la plus chargée de la saison des impôts.
Pour résoudre ce problème, Tax AI a traité 7 000 déclarations de revenus dans les cabinets Crete ayant participé au projet pilote pendant cette saison des impôts. Le système automatise une grande partie du processus long de préparation des déclarations 1040 et 1041, mais ce qui est encore plus convaincant que les gains d’efficacité, c’est que le système lui-même est mesurablement meilleur que la version déployée pour la première fois il y a trois mois.
Dans Tax AI, les praticiens téléversent les fichiers sources avec toutes les notes propres au client. Tax AI crée ensuite une soumission au moteur fiscal, prête à être révisée. Il fait gagner aux praticiens environ le tiers de leur temps de préparation fiscale, rédige des déclarations avec une précision allant jusqu’à 97 % et augmente le débit d’environ 50 %, ce qui leur laisse plus de temps à consacrer aux clients.
Nous pouvons quantifier cette amélioration en comprenant avec quelle précision Tax AI peut compléter une déclaration sans nécessiter de correction par la suite. Nous mesurons la précision en vérifiant quelle part des déclarations atteint 75 %, 90 % ou 100 % d’achèvement correct des champs. Au lancement, seulement un quart des déclarations atteignaient 75 % d’achèvement correct des champs, mais en six semaines, 86 % avaient atteint ce seuil. Le système a montré une croissance encore plus rapide aux niveaux de 90 % et 100 % d’achèvement correct des champs. Ces seuils nous donnent une vue pratique de l’ampleur du suivi que différentes déclarations exigent encore de la part des praticiens.
Au début, Tax AI prenait en charge des tâches plus simples, comme les W-2 et les 1099. Au fil de la saison, il est passé à des déclarations plus complexes avec des K-1, des annexes et des cas limites plus difficiles. Chaque nouvelle capacité faisait gagner plus de temps par déclaration que la précédente, parce que les tâches prises en charge étaient plus difficiles et plus longues à faire manuellement. Nous continuons d’observer des progrès aujourd’hui.
Ensuite, nous verrons comment nos équipes ont co-conçu Tax AI pour qu’il s’autoaméliore en s’appuyant sur trois piliers essentiels : 1) la rétroaction de praticiens experts, 2) les traces de production (un historique structuré des entrées jusqu’à la sortie finale), et 3) une boucle d’itération pilotée par Codex fondée sur des evals adaptées pour permettre un développement produit continu et plus rapide. Nous espérons que notre expérience sera utile à d’autres bâtisseurs dans des domaines où l’expertise des praticiens est essentielle pour façonner la qualité du système global et des données qui le traversent.
À mesure que Tax AI s’est étendu à des déclarations plus complexes, la part des déclarations évaluées atteignant 75 %, 90 % et l’achèvement complet a continué d’augmenter pendant la saison des impôts.
À mesure que nous avancions dans les parties plus difficiles de la préparation fiscale (K-1, annexes de biens immobiliers locatifs et formulaires fiscaux où les valeurs devaient être rapprochées entre plusieurs fichiers sources), il est devenu évident que le véritable défi était de savoir si le produit pouvait rendre les défaillances complexes de production visibles, compréhensibles et exploitables.
Aux débuts du produit, la majeure partie des corrections était manuelle. Les praticiens pouvaient corriger les erreurs du système, mais le produit ne captait pas tout le contexte : une valeur modifiée avant la production pouvait refléter un véritable échec d’extraction, un problème de mappage, un manque de prise en charge par le produit ou du bruit attendu du flux de travail. Le tri de ces cas exigeait encore un suivi de l’équipe d’ingénierie. Les ingénieurs pouvaient utiliser des agents de codage, mais le système n’était pas encore conçu pour utiliser l’IA de façon significative dans une boucle d’amélioration. Nous n’avions pas le signal nécessaire pour identifier la bonne pente à gravir.
Cela nous a amenés à concevoir le système autour de trois piliers :
- Rester près des praticiens : Les personnes qui font le travail doivent orienter ce que le produit apprend. Leur intuition et leur compréhension révèlent quelles erreurs comptent et aident à déterminer sur quelles parties du flux de travail il vaut la peine de se concentrer ensuite.
- Construire le produit pour que la production crée des preuves : Le produit doit capter plus que les entrées et les sorties; il doit saisir tout le parcours, du matériel source aux champs extraits et à leur provenance, jusqu’à la soumission en aval et à la correction par l’expert.
- Créer une boucle d’amélioration pilotée par Codex : Une fois les problèmes de production visibles et structurés, ils peuvent devenir des constatations, des evals adaptées et des tâches d’ingénierie délimitées. Codex peut alors aider à enquêter, proposer des changements, les valider par rapport à des evals ciblées et de régression, et faire avancer le produit plus vite qu’un cycle d’itération purement manuel.
L’exemple des biens locatifs ci-dessous montre comment cette boucle fonctionne en pratique, en vous expliquant comment une correction du praticien devient une constatation structurée, puis une cible d’évaluation, et enfin une tâche d’ingénierie délimitée pour Codex.
Le revenu de bien locatif est déclaré à l’Annexe E d’une déclaration de revenus de particulier. Du point de vue de l’ingénierie, la tâche d’extraction est simple à décrire, mais difficile à bien exécuter. Le système doit lire du matériel source désordonné (notes manuscrites, courriels, feuilles de calcul et autres fichiers clients), extraire les champs de biens locatifs que le système peut mapper avec confiance au moteur fiscal, et préserver suffisamment de preuves pour qu’un praticien puisse approuver ou corriger le résultat. L’exemple simplifié ci-dessous montre à quoi peuvent ressembler ces fichiers sources et ces sorties extraites.
Un ensemble source de biens locatifs est normalisé en champs cités avant d’être mappé aux concepts du moteur fiscal en aval.
Une différence entre la valeur prédite par l’agent et la valeur réelle de la déclaration de revenus produite peut refléter un véritable échec d’extraction, mais elle peut aussi correspondre à une préférence du praticien, à une valeur reportée d’une déclaration de l’année précédente dans le moteur fiscal, ou à une valeur introduite ou modifiée ailleurs dans le flux de production de la déclaration. Les praticiens nous ont aidés à distinguer ces cas afin que nous puissions déterminer quelles actions exigeaient une correction du praticien ou bloquaient une soumission.
Comme nous pouvions voir ces corrections en détail, nous avons transformé le processus de révision, qui était une étape terminale après l’échec, en un cycle d’apprentissage continu. Nous avons conçu le flux de travail pour capter les actions des experts sous forme de données structurées. Maintenant, chaque intervention alimente la boucle d’amélioration du produit en enregistrant exactement ce que Tax AI a proposé, ce que le praticien a modifié et ce qui a finalement été inclus dans la déclaration produite.
Pour un flux de travail complexe comme celui des biens locatifs, le système doit préserver ce qui se passe entre les fichiers sources et la déclaration produite. Sur ce parcours, les documents sont organisés, divisés et classés; les champs des biens locatifs sont extraits avec des citations renvoyant au matériel source; ces valeurs sont mappées dans le moteur fiscal; et les praticiens peuvent encore les corriger avant la production. Ces traces au niveau du produit permettent d’enquêter sur l’endroit où une défaillance s’est produite. Pour transformer les corrections des praticiens en cibles d’évaluation utiles, le système les traite en trois étapes :
- Capturer la différence : La sortie de Tax AI est comparée à la déclaration produite afin de générer des lignes de révision au niveau des champs qui saisissent la valeur attendue, la valeur prédite et si la différence semble exploitable.
- Regrouper les défaillances liées : Les lignes de révision semblables sont regroupées pour séparer les défaillances récurrentes du produit du bruit attendu du flux de travail. Par exemple, des corrections répétées par les praticiens peuvent montrer que Tax AI omet souvent les champs des « jours de location à juste valeur », gère mal les « autres dépenses » ou confond plusieurs biens locatifs dans un même ensemble source.
- Transformer les tendances répétées en cibles d’évaluation : Une fois examinées et mesurées, les constatations répétées deviennent des cibles d’évaluation claires à améliorer pour Codex.
Les lignes de révision des biens locatifs séparent les défaillances récurrentes du produit du bruit attendu, puis transforment les cas exploitables en cibles d’évaluation qui donnent à Codex une pente à gravir.
Le troisième pilier consiste à créer une boucle d’ingénierie capable d’agir sur ces nouvelles evals. C’est là que Codex devient central.
Supposons que notre pipeline d’evals signale que Tax AI omet systématiquement le champ « fair rental days », tandis que les praticiens le remplissent de façon fiable. Comme cette constatation a déjà été regroupée dans un ensemble d’évaluation ciblé, avec des ensembles sources représentatifs et des sorties attendues, Codex peut enquêter directement sur la cause fondamentale dans l’échafaudage du produit.
Codex ne travaille pas seulement à partir d’une sortie finale médiocre. Il inspecte ensemble la trace, l’eval, le dépôt et les compétences :
- Enquêter sur le pipeline : Inspecter les ensembles sources, les schémas d’extraction, le comportement du mappeur et les chemins de code pour déterminer si le problème vient d’un champ non pris en charge, d’un motif d’extraction manqué, d’un problème de sélection de source, d’une lacune du mappeur ou d’un problème d’évaluateur.
- Mettre en œuvre des correctifs ciblés : Étendre le schéma d’extraction, améliorer la sélection des sources pour les documents de biens locatifs, mettre à jour le mappeur du moteur fiscal ou affiner l’évaluateur si du bruit attendu du flux de travail est compté comme une défaillance.
- Valider et proposer : Relancer l’eval ciblée, exécuter des suites de régression plus larges et présenter une pull request candidate pour examen par l’ingénierie.
- Boucler la boucle : Transformer une correction récurrente du praticien en tâche d’ingénierie mesurable. Si les preuves sont ambiguës ou ne peuvent pas être automatisées de façon sûre, le cas est renvoyé à l’équipe produit au lieu d’être forcé dans la boucle.
La boucle complète d’autoamélioration : les traces de production font ressortir les corrections répétées au niveau des champs, qui deviennent des signaux d’échec que Codex peut examiner avec la trace, les évaluations, le dépôt et les compétences. Les tendances exploitables deviennent des evals bornées et des changements de produit candidats; les cas ambigus sont renvoyés aux ingénieurs pour examen. Chaque amélioration livrée crée de nouvelles preuves de production pour le cycle suivant.
L’exemple des biens locatifs illustre un modèle réutilisable plus large : utiliser les artefacts et les traces de production pour améliorer les capacités d’un agent. À partir de constatations examinées issues de données de production, de traces sources, de la sortie attendue du moteur fiscal, d’exemples de code pertinents et de commandes d’eval comme ensemble d’entrées, Codex peut améliorer concrètement les performances et la précision au fil des semaines et des mois. Cela s’appuie sur les principes décrits dans notre travail sur l’ingénierie de harness et Symphony, qui expliquent comment rendre les tâches lisibles pour Codex, fournir un contexte et des outils délimités, et garder la validation et la révision humaine dans l’environnement.
Ces preuves ne deviennent pas automatiquement une tâche pour Codex. Une correction du praticien peut refléter un échec d’extraction, un problème de mappage, un comportement produit non pris en charge, un jugement fiscal ou du bruit attendu du flux de travail. Ce n’est qu’après examen de différences répétées et leur regroupement en une constatation exploitable que le système les transforme en tâche bornée avec une condition de réussite claire.
Nous appliquons cette automatisation à une couche bornée du produit. Cette couche effectue l’extraction et mappe les documents sources dans les flux de travail fiscaux. Les ingénieurs demeurent responsables de l’architecture, des décisions produit et de la mise en production. Les praticiens orientent la boucle d’amélioration par le travail qu’ils font déjà : corriger les valeurs extraites, réviser les déclarations et approuver les productions finales.
Pour Codex, le résultat n’est pas une alerte vague, mais une tâche d’ingénierie délimitée avec des preuves, des surfaces produit modifiables et des portes de validation explicites. Le contexte d’une tâche représentative sur les biens locatifs peut se résumer ainsi :
La même boucle s’applique au-delà des biens locatifs. Les biens locatifs ont pris environ six semaines et une supervision importante de l’ingénierie pour atteindre 90 % de précision et de rappel, mais ce travail a produit des abstractions réutilisables, des artefacts de révision, des conventions d’eval et des modèles d’implémentation qui ont facilité la prise en charge d’annexes tout aussi complexes, comme l’Annexe C et l’Annexe A.
Tax AI démontre une voie pour construire des agents qui s’autoaméliorent. Les praticiens génèrent des signaux de rétroaction à forte valeur en fournissant le service. Les flux de travail du produit préservent ces signaux comme preuves structurées. Les systèmes d’ingénierie appuyés par des evaluations valident les améliorations avant qu’elles n’atteignent la production, et une boucle propulsée par agent maintient le système dans un flux continu d’autoamélioration.
La structure de Thrive Holdings nous permet de reproduire cet environnement dans des secteurs précis. Holdings est à la fois propriétaire et opérateur, donc nos équipes d’ingénierie combinées peuvent travailler directement avec les praticiens et les données de production au sein d’entreprises comme Crete, non pas comme fournisseur, mais comme partenaires. Cela signifie que la technologie, le produit et le service se trouvent tous sous un même toit, ce qui nous aide à avancer plus vite et à bâtir des produits exceptionnels.
Une comptable principale qui avait consacré 180 heures à la préparation fiscale l’an dernier n’y a consacré que 15 heures cette année. Elle a consacré une partie de ce temps à appeler chacun de ses clients et à passer en revue leur déclaration avec eux, un niveau de service très personnalisé qui n’était pas possible il y a un an. Le reste de ce temps, elle l’a utilisé pour prendre de nouveaux clients et élargir l’offre de services.
Ensemble, nos équipes utilisent maintenant le même design en trois parties de Tax AI comme plan directeur pour bâtir des flux de travail dans d’autres domaines à travers Thrive Holdings(s'ouvre dans une nouvelle fenêtre); des flux comptables comme la tenue de livres et l’audit, ainsi que des flux opérationnels comme l’automatisation du centre d’assistance TI. Dans tous les domaines et secteurs, la promesse plus large des agents qui s’autoaméliorent tient toujours. Les meilleurs agents sont guidés par des personnes pour apprendre à devenir plus capables, plus fiables et plus précieux au fil du temps.
Pour en savoir plus sur l’équipe d’OpenAI qui a travaillé sur ce projet, communiquez avec nous.


