Créer des agents fiscaux auto-améliorants avec Codex

Comment Thrive Holdings et OpenAI ont co-développé Tax AI pour les comptables de Crete en fusionnant l’expertise des praticiens avec une boucle pilotée par Codex

Les systèmes réels se comportent différemment en production que dans un environnement de test et échouent souvent de manière difficile à anticiper avant leur déploiement. Les équipes découvrent fréquemment ces défaillances après le lancement, puis passent des semaines à examiner des cas limites, à ajuster les prompts et à transformer les retours issus de la production en améliorations durables du produit. Cette boucle de rétroaction est manuelle et lente, et ne progresse que lorsqu’un ingénieur la fait avancer. Aujourd’hui, toutefois, grâce à une infrastructure d’évaluation soigneusement conçue, à un accès direct aux professionnels et aux environnements réels, ainsi qu’aux capacités agentiques de pointe de Codex, il est possible de créer des agents capables de s’améliorer continuellement.

Dans cet article, nous expliquons comment nous avons utilisé Codex pour créer ce type d’agent. Au cours des six derniers mois, des ingénieurs et chercheurs d’OpenAI intégrés sur le terrain ont collaboré avec les équipes d’ingénierie de Thrive Holdings pour développer Tax AI aux côtés du réseau de plus de 30 cabinets comptables de Crete⁠(ouverture dans une nouvelle fenêtre) et à son intention, afin de les aider à traiter des déclarations fiscales toujours plus complexes. Plutôt que de s’appuyer sur des ingénieurs pour identifier et corriger chaque défaillance, Tax AI utilise Codex pour transformer l’usage en production en signaux structurés qui alimentent un processus d’amélioration autonome.

Chaque saison, les praticiens de Crete préparent des dizaines de milliers de déclarations fiscales, 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 des calculs manuels. Ils nous ont indiqué que la préparation fiscale constituait un goulot d’étranglement majeur pendant la période la plus chargée de la saison fiscale.

Pour relever ce défi, Tax AI a traité 7 000 déclarations fiscales au sein des cabinets Crete ayant participé au pilote pendant cette saison fiscale. Le système automatise une grande partie du travail chronophage nécessaire à la préparation des déclarations fiscales 1040 et 1041. Plus remarquable encore que les gains d’efficacité obtenus, le système affiche aujourd’hui des performances mesurablement supérieures à celles de la version déployée il y a trois mois.

Dans Tax AI, les praticiens téléversent les fichiers source ainsi que toutes les notes spécifiques au client. Tax AI crée ensuite une soumission au moteur fiscal, prête à être revue. Il leur fait gagner environ un tiers du temps consacré à la préparation fiscale, rédige des déclarations avec jusqu’à 97 % de précision et augmente le débit d’environ 50 %, leur laissant plus de temps à consacrer aux clients. 

Nous pouvons quantifier cette amélioration en mesurant dans quelle mesure Tax AI est capable de compléter une déclaration sans nécessiter de correction ultérieure. Nous évaluons cette précision en déterminant la part des déclarations atteignant 75 %, 90 % ou 100 % de champs correctement renseignés. Au lancement, seul un quart des déclarations atteignait le seuil de 75 % de champs correctement renseignés. Six semaines plus tard, cette proportion atteignait 86 %. Le système a progressé encore plus rapidement aux seuils de 90 % et de 100 % de champs correctement renseignés. Ces seuils nous offrent une mesure concrète du niveau d’intervention qui reste nécessaire de la part des professionnels selon les déclarations. 

Au début, Tax AI traitait 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 schedules et des cas limites plus difficiles. Chaque nouvelle capacité faisait gagner plus de temps par déclaration que la précédente, car les tâches prises en charge étaient plus difficiles et plus chronophages à effectuer manuellement. Nous continuons à constater des progrès aujourd’hui.

Nous allons maintenant expliquer comment nos équipes ont co-conçu Tax AI afin qu’il puisse s’améliorer continuellement en s’appuyant sur trois piliers essentiels : 1) les retours de professionnels experts, 2) les traces de production (un historique structuré allant des données d’entrée jusqu’au résultat final) et 3) une boucle d’itération pilotée par Codex reposant sur des évaluations sur mesure permettant d’accélérer et de pérenniser le développement du produit. Nous espérons que cette expérience sera utile à d’autres concepteurs de systèmes dans des domaines où l’expertise métier joue un rôle déterminant dans la qualité du système dans son ensemble ainsi que des données qui l’alimentent.

À mesure que nous avancions vers les parties les plus difficiles de la préparation fiscale (K-1, états de biens locatifs et formulaires fiscaux où les valeurs devaient être rapprochées entre plusieurs fichiers source), 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 plupart des corrections étaient effectuées manuellement. Les professionnels pouvaient corriger les erreurs du système, mais le produit ne capturait pas l’ensemble du contexte : une valeur modifiée avant le dépôt de la déclaration pouvait refléter une véritable erreur d’extraction, un problème de correspondance, une fonctionnalité encore non prise en charge par le produit ou simplement du bruit opérationnel attendu. Distinguer ces différents cas nécessitait encore l’intervention de l’équipe d’ingénierie. Les ingénieurs pouvaient s’appuyer sur des agents de codage, mais le système n’était pas encore conçu pour exploiter l’IA de manière significative dans une boucle d’amélioration continue. Nous ne disposions pas encore des signaux nécessaires pour identifier le problème le plus pertinent à résoudre.

Cela nous a conduits à concevoir le système autour de trois piliers :

1. Rester au plus près des professionnels : les personnes qui effectuent le travail doivent orienter ce que le produit apprend. Leur intuition et leur compréhension du métier permettent d’identifier les erreurs qui comptent réellement et d’éclairer les aspects du workflow sur lesquels concentrer les efforts ensuite.
2. Concevoir le produit afin que la production produise des éléments probants : le produit doit enregistrer bien plus que les seules entrées et sorties. Il doit conserver l’ensemble de la chaîne, depuis les documents sources jusqu’à la soumission finale et aux corrections d’experts, en passant par les champs extraits et leur traçabilité.
3. 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 constats, 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 professionnel devient un constat structuré, puis une cible d’eval, et enfin une tâche d’ingénierie délimitée pour Codex.

Les revenus locatifs sont déclarés dans le formulaire Schedule E d’une déclaration de revenus des particuliers. D’un point de vue technique, la tâche est simple à décrire, mais difficile à exécuter correctement. Le système doit analyser des documents sources hétérogènes (notes manuscrites, e-mails, feuilles de calcul et autres documents fournis par les clients), extraire les données relatives aux biens locatifs qu’il peut associer de manière fiable au moteur fiscal, puis conserver suffisamment d’éléments probants pour qu’un professionnel puisse valider ou corriger le résultat. L’exemple simplifié ci-dessous illustre le type de documents sources et de données extraites que le système peut produire.

Une différence entre la valeur prédite par l’agent et la valeur réelle de la déclaration fiscale déposée 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 déclaration. Les praticiens nous ont aidés à distinguer ces cas afin d’identifier quelles actions nécessitaient une correction du praticien ou bloquaient un dépôt.

Comme nous pouvions voir ces corrections en détail, nous avons transformé le processus de revue, d’une étape terminale après échec, en un cycle d’apprentissage continu. Nous avons conçu le workflow pour capturer les actions des experts sous forme de données structurées. Désormais, 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é intégré à la déclaration déposée.

Pour un workflow complexe comme celui des biens locatifs, le système doit préserver ce qui se passe entre les fichiers source et la déclaration déposée. Tout au long de ce parcours, les documents sont organisés, scindés et classés ; les champs des biens locatifs sont extraits avec des citations renvoyant au matériau source ; ces valeurs sont mappées dans le moteur fiscal ; et les praticiens peuvent encore les corriger avant le dépôt. Ces traces au niveau 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 :

• Identifier les écarts : les résultats de Tax AI sont comparés à la déclaration déposée afin de produire, pour chaque champ, une ligne de revue indiquant la valeur attendue, la valeur prédite et si l’écart paraît exploitable.
• Regrouper les erreurs apparentées : les lignes de revue similaires sont regroupées afin de distinguer les défaillances récurrentes du produit du bruit normal du workflow. Par exemple, des corrections répétées effectuées par les professionnels peuvent révéler que Tax AI omet fréquemment les champs relatifs aux jours de location à valeur locative normale, traite incorrectement les « autres dépenses » ou confond plusieurs biens locatifs au sein d’un même ensemble de données source.
• Transformer les motifs répétés en cibles d’évaluation : une fois revus et mesurés, les constats répétés deviennent des cibles d’évaluation claires à améliorer pour Codex.

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’évaluation détecte que Tax AI omet systématiquement le champ « jours de location à valeur locative normale », alors que les professionnels le renseignent de manière fiable. Comme ce problème a déjà été intégré à un ensemble d’évaluation ciblé, comprenant des dossiers sources représentatifs et les résultats attendus, Codex peut en rechercher directement la cause profonde au sein de l’architecture du produit.

Codex ne travaille pas uniquement à partir d’une sortie finale médiocre. Il inspecte ensemble la trace, l’eval, le dépôt et les skills :

• Examiner le pipeline : analyser les dossiers sources, les schémas d’extraction, le comportement des modules de correspondance et les chemins d’exécution du code afin de déterminer si le problème provient d’un champ non pris en charge, d’un modèle d’extraction non détecté, d’un problème de sélection des sources, d’une lacune dans la logique de correspondance ou d’un problème lié à l’évaluateur.
• Mettre en œuvre des correctifs ciblés : étendre le schéma d’extraction, améliorer la sélection des sources pour les documents relatifs aux biens locatifs, mettre à jour la logique de correspondance du moteur fiscal ou affiner l’évaluateur si du bruit opérationnel attendu est comptabilisé à tort comme une erreur.
• Valider et proposer : relancer l’eval ciblée, exécuter des suites de régression plus larges et soumettre une pull request candidate à l’examen de l’équipe d’ingénierie.
• Boucler la boucle : transformer une correction récurrente apportée par un professionnel en une tâche d’ingénierie mesurable. Si les éléments probants sont ambigus ou si le traitement ne peut pas être automatisé de manière sûre, le dossier est réorienté vers l’équipe produit plutôt que d’être intégré de force au processus.

L’exemple des biens locatifs illustre un schéma réutilisable plus large : exploiter les artefacts et les traces issus de la production pour améliorer les capacités d’un agent. À partir d’un ensemble d’entrées comprenant des constats validés issus des données de production, des traces sources, les résultats attendus du moteur fiscal, des exemples de code pertinents et des commandes d’évaluation, Codex peut améliorer de manière significative ses performances et sa précision au fil des semaines et des mois. Cette approche s’appuie sur les principes décrits dans nos travaux sur l’ingénierie des infrastructures d’évaluation et Symphony, qui expliquent comment rendre les tâches compréhensibles pour Codex, lui fournir un contexte et des outils circonscrits, et faire de la validation et de la revue humaine des composantes intégrées de 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 mapping, un comportement produit non pris en charge, un jugement fiscal ou le bruit attendu du workflow. Ce n’est qu’après examen de différences répétées et leur regroupement en un constat 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 source vers les workflows fiscaux. Les ingénieurs restent responsables de l’architecture, des décisions produit et de la mise en production. Les praticiens orientent la boucle d’amélioration à travers le travail qu’ils font déjà : corriger les valeurs extraites, revoir les déclarations et approuver les dépôts finaux.

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 être résumé comme suit :

La même boucle s’applique au-delà des biens locatifs. Les biens locatifs ont nécessité environ six semaines de travail et une supervision technique importante pour atteindre 90 % de précision et de rappel, mais ce travail a permis de créer des abstractions réutilisables, des artefacts de revue, des conventions d’évaluation et des modèles d’implémentation qui ont facilité la prise en charge d’annexes fiscales tout aussi complexes, comme les formulaires Schedule C et Schedule A.

Tax AI montre une voie pour construire des agents auto-améliorants. Les praticiens génèrent des signaux de retour à forte valeur en fournissant le service. Les workflows produit préservent ces signaux comme preuves structurées. Des systèmes d’ingénierie appuyés par des evals valident les améliorations avant leur arrivée en production, et une boucle pilotée par agent maintient le système dans un flux continu d’auto-amélioration. 

La structure de Thrive Holdings nous permet de répliquer cet environnement dans des secteurs spécifiques. Holdings est à la fois propriétaire et opérateur, de sorte que 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 sont tous réunis sous un même toit pour nous aider à aller plus vite et à construire des produits exceptionnels.

Une comptable senior qui avait consacré 180 heures à la préparation fiscale l’an dernier n’y a passé que 15 heures cette année. Elle a consacré une partie de ce temps à appeler chacun de ses clients et à parcourir avec eux leurs déclarations, un niveau de service très personnalisé qui n’était pas possible il y a un an. Elle a utilisé le reste de ce temps pour prendre de nouveaux clients et élargir l’offre de services.

Ensemble, nos équipes utilisent désormais le même modèle en trois volets issu de Tax AI comme plan directeur pour concevoir des workflows dans d’autres domaines au sein de Thrive Holdings⁠(ouverture dans une nouvelle fenêtre), qu’il s’agisse de processus comptables comme la tenue de livres et l’audit, ou de processus opérationnels comme l’automatisation du support informatique. Tous secteurs et domaines confondus, la promesse plus large des agents capables de s’améliorer eux-mêmes reste intacte. Les meilleurs agents sont guidés par des humains afin d’apprendre, au fil du temps, à devenir plus performants, plus fiables et plus utiles.

Pour en savoir plus sur l’équipe OpenAI qui a travaillé sur ce projet, contactez-nous.